Fedora-Fr

losange · 2014-06-22T09:46:43+00:00

Bonjour, J'ai installé Fedora 20 il y a 3 mois, venant d'Ubuntu. Très satisfait au début, j'ai quelques problèmes depuis une quinzaine de jours suite à une m...

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Perte de son,USB, config imprimante, et autres bugs suite à maj

Heldwin

Un /dev/sda1 en ext4 de 500 MB ?

Ca ressemble a une partition /boot ça. Elle est montée ?

mount

df -hT

Si elle n'est pas montée:

mount /dev/sda1 /boot

Puis, regarder ce qu'il y a dans /boot après son montage.
Il faudrait aussi le contenu de /etc/fstab.

Si ça utilise les UUID, il faudrait le retour de:

blkid

losange

Réponses : 1) @chepiok

# find / -name "kernel"
find: ‘/proc/sys/fs/binfmt_misc’: Aucun périphérique de ce type
/proc/sys/kernel
/etc/kernel
/etc/sysconfig/kernel
/usr/lib64/pm-utils/module.d/kernel
/usr/lib/modules/3.14.8-200.fc20.x86_64/kernel
/usr/lib/modules/3.14.8-200.fc20.x86_64/kernel/kernel
/usr/lib/modules/3.14.8-200.fc20.x86_64/kernel/arch/x86/kernel
/usr/lib/modules/3.14.7-200.fc20.x86_64/kernel
/usr/lib/modules/3.14.7-200.fc20.x86_64/kernel/kernel
/usr/lib/modules/3.14.7-200.fc20.x86_64/kernel/arch/x86/kernel
/usr/lib/modules/3.14.5-200.fc20.x86_64/kernel
/usr/lib/modules/3.14.5-200.fc20.x86_64/kernel/kernel
/usr/lib/modules/3.14.5-200.fc20.x86_64/kernel/arch/x86/kernel
/usr/lib/kernel
/var/tmp/abrt/ccpp-2014-05-01-15:33:03-752/kernel
/var/tmp/abrt/ccpp-2014-06-05-17:04:35-1607/kernel
/var/tmp/abrt/ccpp-2014-04-23-14:30:15-1432/kernel
/var/tmp/abrt/ccpp-2014-05-25-12:10:09-4197/kernel
/var/tmp/abrt/ccpp-2014-05-01-15:17:56-5532/kernel
/var/tmp/abrt/ccpp-2014-05-26-22:48:49-4157/kernel
/var/tmp/abrt/ccpp-2014-06-23-23:09:14-1125/kernel
/var/tmp/abrt/ccpp-2014-04-03-19:46:24-3823/kernel
/sys/fs/selinux/initial_contexts/kernel
/sys/devices/virtual/drm/ttm/memory_accounting/kernel
/sys/kernel
/sys/module/kernel

# find / -name "grub2"
find: ‘/proc/sys/fs/binfmt_misc’: Aucun périphérique de ce type
/usr/share/doc/grub2

3) @Heldwin, après montage

[root@localhost boot]# ls
config-3.13.10-200.fc20.x86_64                           initrd-plymouth.img
config-3.13.8-200.fc20.x86_64                            lost+found
config-3.13.9-200.fc20.x86_64                            memtest86+-5.01
efi                                                      System.map-3.13.10-200.fc20.x86_64
elf-memtest86+-5.01                                      System.map-3.13.8-200.fc20.x86_64
extlinux                                                 System.map-3.13.9-200.fc20.x86_64
grub2                                                    vmlinuz-0-rescue-c2609334db024227ad88773717329594
initramfs-0-rescue-c2609334db024227ad88773717329594.img  vmlinuz-3.13.10-200.fc20.x86_64
initramfs-3.13.10-200.fc20.x86_64.img                    vmlinuz-3.13.8-200.fc20.x86_64
initramfs-3.13.8-200.fc20.x86_64.img                     vmlinuz-3.13.9-200.fc20.x86_64
initramfs-3.13.9-200.fc20.x86_64.img

Ca me parait mieux.
Je constate donc que j'ai une partition sda1 de 500Mb qui est non montée au démarrage, mais qui une fois montée, ne contient que des fichiers d'anciens noyaux.
4)

# blkid
/dev/sda1: UUID="ede1e15d-9cfd-44e6-8cfe-7fa2d878061b" TYPE="ext4" PARTUUID="0007fc8e-01" 
/dev/sda2: UUID="Adj93u-Sijq-m4yp-uFfm-0QsD-jjbM-pDoaGg" TYPE="LVM2_member" PARTUUID="0007fc8e-02" 
/dev/mapper/fedora-swap: UUID="aa945558-2c87-410c-8854-a23cc1386e58" TYPE="swap" 
/dev/mapper/fedora-root: UUID="7b343a9a-364d-4f8e-b235-b9f185d94ced" TYPE="ext4" 
/dev/mapper/fedora-home: UUID="e1f39322-0138-4e89-8683-2392d7a8336a" TYPE="ext4"

Je suis toujours en cours de sauvegarde, donc je n'ai pas encore appliqué les solutions proposées (toujours en phase de diagnostique, quoi)
Pour les kernel en 3.14, ils sont peut-être là depuis que j'ai fait la mise à jour manuelle, mais je ne suis pas sûr de mon coup.

nouvo09

regarde dans ton fichier /etc/fstab si la partition / est bien prévue d'être montée au démarrage ?

losange

Voilà le contenu de /etc/fstab
#
# /etc/fstab
# Created by anaconda on Sat Mar 29 12:32:19 2014
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/fedora-root / ext4 defaults 1 1
/dev/mapper/fedora-home /home ext4 defaults 1 2
/dev/mapper/fedora-swap swap swap defaults 0 0

Donc, créé quand j'ai fait ma première install de Fedora avec le liveDVD.

paradise

losange wrote:
Donc, créé quand j'ai fait ma première install de Fedora avec le liveDVD.

J'avais noté ce détail plus haut, ton installation à partir d'un LiveDVD...

Alors que le plus sûr est d'installer avec un iso complet sur DVD, ou clef USB.

Bon, à présent, il faudrait réparer ta Fedora, là j'avoue que c'est hard, il manque des fichiers importants... 🙁

Personnellement, je referais (lâchement) une installation propre... :hammer:

losange

De toute façon, je fais mes sauvegardes un peu dans cette optique...
A moins qu'une petite solution simple me fasse gagner beaucoup de temps.

Heldwin

S'il y a une partition /boot, elle est manquante dans /etc/fstab.

Il faudrait rajouter avant la ligne: /dev/mapper/fedora-root

UUID=ede1e15d-9cfd-44e6-8cfe-7fa2d878061b     /boot                   ext4    defaults                      1 2

/dev/sda1				  /boot           ext4    defaults			 		  	1 2

Selon si ça utilise les UUID ou non.
Le fait que /boot ne soit plus (?) dans /etc/fstab, me dirait d'essayer en 1er en mettant /dev/sda1

Une fois que /boot sera à nouveau là, il faudrait essayer:

yum distro-sync

afin de faire une synchro des paquets installées avec ceux des repos.

Tu peux après ça essayer un:

rpm -Va > /tmp/rpm-check.txt 2>&1

afin de vérifier les paquets installés et d'avoir ça dans un fichier.

Il n'y a rien dans: yum history , qui pourrait indiquer ce qui s'est passé durant cette mise à jour ? (ou peut-être un fichier de logs)
(yum history indique parfois des erreurs qui sont passées inaperçues)

chepioq

Ce qui m'interpelle, c'est que si /boot n'est pas monté au démarrage, sur quoi l'ordi démarre ?
Il y a un deuxième /boot quelque part ?

nouvo09

Non le processus de boot recherche ses petits non d'après fstab, qui n'est pas encore lu, mais d'après les indications inscrites lors du processus de grub2-install dans le MBR (ou la piste 0)

losange

On avance, donc :
après avoir édité /etc/fstab et ajouté : /dev/sda1 /boot ext4 defaults 1 2
La partition sda1 est bien montée après redémarage.
Pas de changements dans la liste des fichiers de /boot
Ensuite : j'ai donc fait :

yum distro-sync
rpm -Va > /tmp/rpm-check.txt 2>&1

Voilà le contenu de /txt/rpm-check.txt :
manque /boot/.vmlinuz-3.14.5-200.fc20.x86_64.hmac
manque /boot/System.map-3.14.5-200.fc20.x86_64
manque /boot/config-3.14.5-200.fc20.x86_64
manque /boot/vmlinuz-3.14.5-200.fc20.x86_64
manque /var/run/pluto
....L.... c /etc/pam.d/fingerprint-auth
....L.... c /etc/pam.d/password-auth
....L.... c /etc/pam.d/postlogin
....L.... c /etc/pam.d/smartcard-auth
....L.... c /etc/pam.d/system-auth
S.5....T. c /etc/hba.conf
S.5....T. /usr/share/applications/defaults.list
.......T. c /etc/kdump.conf
manque /var/run/gluster
.M....G.. /var/log/gdm
SM5....T. c /etc/ccpd.conf
manque /var/run/wpa_supplicant
S.5....T. /boot/elf-memtest86+-5.01
S.5....T. /boot/memtest86+-5.01
S.5....T. c /etc/printcap
.M....G.. /var/log/journal
S.5....T. /usr/lib64/vlc/plugins/plugins.dat
S.5....T. c /etc/cups/cups-browsed.conf
manque /boot/.vmlinuz-3.14.8-200.fc20.x86_64.hmac
manque /boot/System.map-3.14.8-200.fc20.x86_64
manque /boot/config-3.14.8-200.fc20.x86_64
manque /boot/vmlinuz-3.14.8-200.fc20.x86_64
manque /boot/.vmlinuz-3.14.7-200.fc20.x86_64.hmac
manque /boot/System.map-3.14.7-200.fc20.x86_64
manque /boot/config-3.14.7-200.fc20.x86_64
manque /boot/vmlinuz-3.14.7-200.fc20.x86_64
manque /usr/java/jre1.7.0_51/lib/install.jar
erreur : %verify(jre-1.7.0_51-fcs.x86_64) scriptlet échoué, état de sortie 5
....L.... c /etc/pam.d/fingerprint-auth
....L.... c /etc/pam.d/password-auth
....L.... c /etc/pam.d/postlogin
....L.... c /etc/pam.d/smartcard-auth
....L.... c /etc/pam.d/system-auth
S.5....T. c /var/lib/unbound/root.key
..5....T. c /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/jre/lib/security/US_export_policy.jar
..5....T. c /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.4.fc20.x86_64/jre/lib/security/local_policy.jar
.M....... /
.M....... /sys
S.5....T. c /etc/pear.conf
S.5....T. c /etc/plymouth/plymouthd.conf
.M....... c /etc/cups/subscriptions.conf

Enfin, le résultat de yum -history :

Modules complémentaires chargés : langpacks, refresh-packagekit
ID     | Identifiant utilisateur  | Date et heure    | Action         | Modifié
-------------------------------------------------------------------------------
    97 | laurent <laurent>        | 2014-06-25 14:49 | Update         |   14   
    96 | laurent <laurent>        | 2014-06-23 21:17 | Update         |    5   
    95 | laurent <laurent>        | 2014-06-22 23:26 | Install        |    1   
    94 | Système <indéfini>       | 2014-06-22 23:05 | Update         |    5   
    93 | Système <indéfini>       | 2014-06-22 13:24 | Update         |   41   
    92 | Système <indéfini>       | 2014-06-20 00:37 | E, I, U        |    7   
    91 | Système <indéfini>       | 2014-06-19 23:01 | Update         |   11   
    90 | Système <indéfini>       | 2014-06-15 18:11 | E, I, U        |   79   
    89 | Système <indéfini>       | 2014-06-15 18:09 | Install        |    1   
    88 | Système <indéfini>       | 2014-06-15 18:08 | Install        |    1   
    87 | Système <indéfini>       | 2014-06-15 18:08 | Install        |    1   
    86 | Système <indéfini>       | 2014-06-15 18:08 | Install        |    4   
    85 | Système <indéfini>       | 2014-06-15 18:07 | Install        |    4   
    84 | Système <indéfini>       | 2014-06-15 18:06 | Erase          |    1   
    83 | laurent <laurent>        | 2014-06-15 15:24 | Install        |    1   
    82 | laurent <laurent>        | 2014-06-14 14:48 | Install        |    1   
    81 | laurent <laurent>        | 2014-06-11 21:24 | Install        |    2   
    80 | Système <indéfini>       | 2014-06-11 17:49 | Update         |   17   
    79 | Système <indéfini>       | 2014-06-08 21:23 | E, I, U        |   62 EE
    78 | Système <indéfini>       | 2014-06-03 14:31 | Update         |   36 EE
history list

Si j'ai bien compris, je n'ai toujours pas le noyau en 3.14 dans /boot. Je vais essayer de les mettre puis de rebooter.

chepioq

Je ne sais pas comment tu vas faire, mais le mieux serait de ré-installer le dernier driver en 3.14

yum reinstall kernel-3.14.8-200.fc20.x86_64

Normalement le script associé devrait le mettre dans grub.

losange

Oui, mais ça coince...

]# yum reinstall kernel-3.14.8-200.fc20.x86_64
Modules complémentaires chargés : langpacks, refresh-packagekit
Paquets installés kernel-3.14.8-200.fc20.x86_64(depuis updates) indisponibles.
Erreur : Rien à faire

J'ai lu dans la doc qu'avant de faire yum -update, il fallait désactiver tous les dépôts non officiels RPM Fusion, RPMForge...
http://doc.fedora-fr.org/wiki/Passer_%C3%A0_la_version_sup%C3%A9rieure_de_Fedora_via_YUM

chepioq

Cette méthode n'est valable que si tu veux passer de Fedora-n à Fedora-n+1 (F20==>F21 par exemple).

Ce qui m’étonne c'est que le paquet soit indisponible chez toi, tu dois avoir des dépôts pas à jour.

Attend un peu et ré-essaye.

nouvo09

Télécharge le paquet là

http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/updates/20/x86_64/

et tu peux faire à partir du répertoire de téléchargement un

yum reinstall ./kernel-3.14.8-200.fc20.x86_64.rpm

losange

Ben voilà, il fallait le dire plus tôt...
kernel-3.14.8-200.fc20.x86_64.rpm téléchargé, installé.
reboot ok en 3.14.8-200
et je retrouve le son, la reconnaissance des disques externes, c'est tout pour ce soir, mais je me coucherai moins bête que ce matin.
L'imprimante, ç'est bon aussi.
Merci à tous pour vos différentes contributions, qui sont complémentaires de surcroit !

Heldwin

chepioq wrote:Ce qui m'interpelle, c'est que si /boot n'est pas monté au démarrage, sur quoi l'ordi démarre ?
Il y a un deuxième /boot quelque part ?

nouvo09 wrote:Non le processus de boot recherche ses petits non d'après fstab, qui n'est pas encore lu, mais d'après les indications inscrites lors du processus de grub2-install dans le MBR (ou la piste 0)

Je ne suis pas tout à fait d'accord avec ça.

Pour moi, la partition /boot montée par /etc/fstab ne sert en effet pas pour le démarrage en lui-même, mais pour pouvoir mettre à jour les noyaux, changer la config de grub2 et autres.
Cependant, le MBR indique où se trouve cette partition /boot, donc pour moi, le système démarre car grub2 était toujours intact sur /dev/sda1 (et le MBR savait où la trouver).

@losange

Profites-en pour démonter la partition /boot et retirer tout ce qui se trouve dans /boot, car les fichiers dedans sont inutiles.
(je dis bien après avoir démonté /boot, pour pas revenir au point de départ, en pire 🙂)

EDIT:

En passant, en 1 seule commande, ça aurait aussi été 🙂

yum reinstall http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/updates/20/x86_64/kernel-3.14.8-200.fc20.x86_64.rpm

ou sans téléchargement direct, ça devrait passer comme ça, si c'est toujours ce kernel qui est disponible:

yum remove kernel-3.14.8-200.fc20.x86_64
yum install kernel-3.14.8-200.fc20.x86_64

Je trouve quand même intéressant de voir que la réinstalle fonctionne en prenant le rpm en http et pas en reinstalle directe.

chepioq

Heldwin wrote:Profites-en pour démonter la partition /boot et retirer tout ce qui se trouve dans /boot, car les fichiers dedans sont inutiles.
(je dis bien après avoir démonté /boot, pour pas revenir au point de départ, en pire 🙂)

Cela ferait en effet un bon nettoyage, mais personnellement je n'y toucherais pas, le nettoyage se fera automatiquement au fur et à mesure de l'installation de nouveau kernel.

Pour verifier redonne nous maintenant le résultat de la commande ls, en étant dans le répertoire /boot.

Tu ne devrais plus avoir que deux kernel en 3.13 et le dernier kernel installé, le 3.14.8-200

VINDICATORs

Étonnant que /boot est sauté dans fstab quand même... Enfin bon on en voit des choses tout les jours que ce soit ici où ailleurs.

Heldwin

chepioq wrote:
Heldwin wrote:Profites-en pour démonter la partition /boot et retirer tout ce qui se trouve dans /boot, car les fichiers dedans sont inutiles.
(je dis bien après avoir démonté /boot, pour pas revenir au point de départ, en pire 🙂)
Cela ferait en effet un bon nettoyage, mais personnellement je n'y toucherais pas, le nettoyage se fera automatiquement au fur et à mesure de l'installation de nouveau kernel.

Non, ça ne se fera pas automatiquement.
Les fichiers qui se sont mis dedans l'ont été car /boot n'était plus monté.

nouvo09

Heldwin wrote:
nouvo09 wrote:Non le processus de boot recherche ses petits non d'après fstab, qui n'est pas encore lu, mais d'après les indications inscrites lors du processus de grub2-install dans le MBR (ou la piste 0)
Je ne suis pas tout à fait d'accord avec ça.

Pour moi, la partition /boot montée par /etc/fstab ne sert en effet pas pour le démarrage en lui-même, mais pour pouvoir mettre à jour les noyaux, changer la config de grub2 et autres.
Cependant, le MBR indique où se trouve cette partition /boot, donc pour moi, le système démarre car grub2 était toujours intact sur /dev/sda1 (et le MBR savait où la trouver).

A quoi bon dire que tu n'es pas d'accord alors que tu dis exactement la même chose que moi ?

« Page précédente Page suivante »