web-dev-qa-db-fra.com

Le système de fichiers du volume lvm est soudainement passé de ext4 à silicon_medley_raid_member

Aujourd'hui, mon ordinateur portable m'a soudainement montré ce texte au démarrage:

mount: mounting /dev/dm-0 on /root failed: No such device
mount: mounting /dev on /root/dev failed: No such file or directory
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
Target filesystem doesn't have requested /sbin/init.
No init found. Try passing init= bootarg.

BusyBox v1.21.1 (Ubuntu 1:1.21.0-1ubuntu1) built-in Shell (ash)
...

j'ai démarré à partir de livecd et vérifié tous les systèmes de fichiers (il y a trois volumes lvm local-root, local-home et local-swap il y a aussi une partition/boot dans/dev/sda1 qui n'est pas en lvm) avec fsck

Même résultat après redémarrage ..

Puis, en montant mes volumes pour chrooting sur eux, j'ai vu que local-root ne peut pas être monté pour cette raison:

# mount /dev/mapper/local-root /mnt
mount: unknown filesystem type 'silicon_medley_raid_member'

Zut! POURQUOI?! pourquoi MOI et MAINTENANT? !!

j'ai vérifié cela deux fois:

# blkid /dev/mapper/local-root
/dev/mapper/local-root: TYPE="silicon_medley_raid_member"

Cependant, je peux toujours le monter facilement avec un fstype défini manuellement:

# mount -t ext4 /dev/mapper/local-root /mnt

Mais je ne sais pas quoi faire ensuite, comment changer FSTYPE en ext4 sans perdre de données? (oui, j'ai une sauvegarde, mais uniquement pour le volume 'local-home', et je ne veux pas réinstaller le système complet maintenant ..)

Merci pour votre temps!

bootgrub2partitioningmountlvm
1
esergion

Je me suis beaucoup amusé avec le même bug aujourd'hui et je ne peux pas compter toutes les vérifications du système de fichiers, les réparations de démarrage, les réinstallations de grub, ...

Il s'avère que la solution est assez simple. Il suffit d'étendre votre volgroup racine de quelques octets et le type sera automatiquement fixé sur ext4.

lvextend -L +512B /dev/mapper/local-root

J'ai trouvé la solution ici: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1011007

1
Nils Eckert

J'ai rencontré un problème similaire. Cependant, mon groupe de volumes LVM était plein, je n'ai donc pas pu essayer le hack mentionné dans l'autre solution.

Au lieu de cela, j'ai utilisé wipefs pour voir que ma partition avait en fait 2 signatures. L'un était correct (ext4). L'autre était incorrect (silicon_medley_raid_member).

J'ai d'abord démarré avec un LiveUSB qui correspondait à ma version d'Ubuntu (14.04). Ensuite, j'ai exécuté ceci pour voir les deux signatures:

Sudo wipefs -n /dev/mapper/local-root

La sortie ressemblait à ceci:

offset               type
----------------------------------------------------------------
0x4444               ext4   [filesystem]
                     LABEL: root
                     UUID:  <redacted>

0xfffffff            silicon_medley_raid_member (raid)

(Les décalages ont été modifiés pour protéger les innocents.)

Ensuite, j'ai exécuté cela pour tester la suppression de la mauvaise signature.

Sudo wipefs -n -o 0xfffffff /dev/mapper/local-root

Où 0xfffffff est le décalage répertorié à partir de la première commande.

Enfin, je l'ai exécuté à nouveau sans -n pour réellement écrire la modification sur le disque.

Sudo wipefs -o <offset> /dev/mapper/local-root

Et maintenant blkid /dev/mapper/local-root montrait le TYPE comme ext4.

Soyez très prudent lorsque vous utilisez wipefs. Vous devriez avoir une sauvegarde avant de le faire. Et certainement n'utilisez pas cette méthode si vous ne voyez pas réellement deux signatures.

0
phylae