système de fichiers ext4 détecté à tort comme jmicron_raid_member
J'ai une installation d'Ubuntu 12.04 sur un disque SSD que je ne peux pas démarrer après une mise à niveau du noyau et un redémarrage. Des choses supplémentaires qui pourraient être une cause possible sont que j'ai fait un peu de nettoyage (dpkg -r) d'anciens noyaux inutilisés (une liste que j'ai sélectionnée manuellement dans dpkg -l | grep linux-).
Voici ce que je peux rassembler en démarrant un système actif (c'est-à-dire en démarrant un autre système d'exploitation) et en essayant d'accéder au disque.
Le disque a deux partitions, la première est une petite partition (sdb1) contenant un système de fichiers/boot ext2, et la seconde est cryptée LUKS, donc je l'ai ouverte en utilisant cryptsetup luksOpen /dev/sdb5 ssd. Le nouveau périphérique est un LVM2 pv donc je le rend disponible avec vgscan puis vgchange -a y. J'ai maintenant un LVM2 vg contenant deux volumes logiques nommés foo-root et foo-swap. Il est foo-root qui contient mon système de fichiers.
C'est maintenant que des choses étranges commencent à se produire. J'essaie de monter le système de fichiers avec mount /dev/mapper/foo-root /mnt qui renvoie:
mount: type de système de fichiers inconnu 'jmicron_raid_member'
J'essaie donc de spécifier le type de système de fichiers mount -t ext4 /dev/mapper/foo-root /mnt, et ça marche. Je suis heureux de pouvoir accéder à mes données, mais comme je ne parviens toujours pas à démarrer le disque, je démonte le système de fichiers et continue à explorer.
Je cours fsck.ext4 -f /dev/mapper/foo-root sans fautes.
À ce stade, il semble que le problème est que le type de système de fichiers est signalé de manière incorrecte. Je cours blkid -p /dev/mapper/foo-root et il renvoie:
/ dev/mapper/foo-root: VERSION = "55.72" TYPE = "jmicron_raid_member" USAGE = "raid"
Un système de fichiers ext4 sain retournerait UUID="along-uuid" TYPE="ext4".
Je me tourne vers Google. Il semble que dmraid pourrait supprimer l'en-tête RAID erroné avec dmraid -Er mais cela ne fonctionne pas. Aussi dmraid -r Retour:
pas de disques de raid
Pour faire bonne mesure, et un peu de sentiment déjà correct, j'essaie dmraid -x et dmraid -Er /dev/mapper/foo-root et ni aide en aucune façon.
En accédant au système de fichiers, j'ai essayé diverses choses comme le chrootage et la reconstruction de l'initrd, la réécriture de grub sur MBR (essayé à la fois sdb et sdb1), et rendre sdb1 amorçable, entre autres. Rien ne semble rendre le disque amorçable à nouveau.
Je n'ai plus d'options. Toute aide est appréciée.
PDATE: Exécution de la commande à partir du commentaire @psusi:
0000000: 4a4d 4837 780a 4744 5851 7033 4d70 5136 JMH7x.GDXQp3MpQ6
0000010: 6c71 5056 4932 4f31 6c49 7155 7646 6359 lqPVI2O1lIqUvFcY
0000020: 414b 382f 7054 766f 5a32 5a57 754c 585a AK8/pTvoZ2ZWuLXZ
0000030: 6e59 7746 5174 4b53 5656 686e 6230 4e4a nYwFQtKSVVhnb0NJ
0000040: 4646 685a 506b 4155 3936 7335 4d69 2f65 FFhZPkAU96s5Mi/e
0000050: 4971 0a67 5346 6a59 4b43 4f2f 536f 5a5a Iq.gSFjYKCO/SoZZ
0000060: 4855 3838 7231 2b6c 4137 4558 326c 704d HU88r1+lA7EX2lpM
0000070: 6e6e 6a74 5463 4d63 2b6c 4959 3131 334c nnjtTcMc+lIY113L
0000080: 6a6f 4b69 4346 4f56 4a42 3635 4641 4675 joKiCFOVJB65FAFu
0000090: 4457 626d 312b 5658 4c4b 4f64 7458 4a0a DWbm1+VXLKOdtXJ.
00000a0: 4e5a 6136 6841 6b6a 5573 6553 6176 6e30 NZa6hAkjUseSavn0
00000b0: 735a 2b7a 5637 6f71 6561 564f 3566 6c7a sZ+zV7oqeaVO5flz
00000c0: 3655 3458 6855 6373 4b6c 4d70 784a 494c 6U4XhUcsKlMpxJIL
00000d0: 612f 3152 6a46 6157 3563 3966 4e6b 4f31 a/1RjFaW5c9fNkO1
00000e0: 4150 6331 6f32 3368 6131 6a62 0a66 6653 APc1o23ha1jb.ffS
00000f0: 2f61 626e 474e 6b66 4559 787a 6e31 4e63 /abnGNkfEYxzn1Nc
0000100: 3157 7139 6b61 526a 6255 3339 4a69 314b 1Wq9kaRjbU39Ji1K
0000110: 3632 5765 6e51 4b6c 7567 3373 5742 4148 62WenQKlug3sWBAH
0000120: 7278 5854 5165 4634 346e 6534 3143 4d33 rxXTQeF44ne41CM3
0000130: 637a 592b 5668 3870 2f0a 4373 7562 5132 czY+Vh8p/.CsubQ2
0000140: 6847 3675 6470 3455 3850 5875 7132 5631 hG6udp4U8PXuq2V1
0000150: 465a 324b 7851 4842 5975 4e75 4354 6a49 FZ2KxQHBYuNuCTjI
0000160: 4866 474b 364f 342b 4851 3036 454a 4a4e HfGK6O4+HQ06EJJN
0000170: 4578 5541 6b4b 546a 5070 7a53 5431 4432 ExUAkKTjPpzST1D2
0000180: 6e4b 506e 6730 0a37 5449 6d44 5478 4462 nKPng0.7TImDTxDb
0000190: 7879 514d 6e30 7761 7a5a 2f45 324a 7047 xyQMn0wazZ/E2JpG
00001a0: 4563 7337 6a6e 4c63 4138 6574 4356 7a4a Ecs7jnLcA8etCVzJ
00001b0: 766e 454c 586e 6957 7868 4639 5038 4132 vnELXniWxhF9P8A2
00001c0: 645a 2f66 3277 7556 794f 344a 3731 4e59 dZ/f2wuVyO4J71NY
00001d0: 5357 6c0a 696b 7364 6a59 7665 7356 4b6f SWl.iksdjYvesVKo
00001e0: 572b 376e 314f 6174 752b 6737 4c59 5732 W+7n1Oatu+g7LYW2
00001f0: 744e 574d 5a6a 765a 3459 5933 7756 696a tNWMZjvZ4YY3wVij
Pour une raison quelconque, il semble que vous ayez une signature jmicron raid à la fin du volume. Vous pouvez l'effacer avec:
Sudo dd if=/dev/zero of=/dev/mapper/foo-root bs=512 seek=$((`Sudo blockdev --getsz /dev/mapper/foo-root` - 1))
Vous devez fsck le système de fichiers après pour vous assurer que rien de mal ne s'est passé, et comme toujours, avoir une sauvegarde.