Récupérer LVM (sur RAID1): Aucun groupe de volumes n'a été trouvé. Table de partition effacée?

J'essaie de récupérer un LVM (pas de encryption) sur un RAID1 en utilisant Debian Live.

Apparemment, le RAID1 peut être assemblé sans problème, mais le LVM est cassé. Vous pouvez passer à la section LVM. La partie RAID est laissée au cas où cela serait important.

La descente

# aptitude install mdadm # mdadm --assemble --scan 

dmesg:

 [ 617.036709] md: md0 stopped. [ 617.038099] md: bind<sdc1> [ 617.038302] md: bind<sda1> [ 617.214903] md: raid1 personality registered for level 1 [ 617.215534] md/raid1:md0: active with 2 out of 2 mirrors [ 617.215694] created bitmap (8 pages) for device md0 [ 617.215956] md0: bitmap initialized from disk: read 1 pages, set 0 of 14903 bits [ 617.682354] md0: detected capacity change from 0 to 1000068874240 [ 617.693821] md0: 

Voici le RAID:

 # ls -l /dev/md0 brw-rw---- 1 root disk 9, 0 Jan 21 19:34 /dev/md0 # mdadm --examine /dev/md0 /dev/md0: MBR Magic : aa55 # file -s /dev/{md0,sda,sdc} /dev/md0: DOS/MBR boot sector /dev/sda: DOS/MBR boot sector /dev/sdc: DOS/MBR boot sector 

J'ai peur que ce DOS/MBR boot sector soit le problème. Plus d'informations plus tard.

Informations supplémentaires, juste au cas où

Ceci n'est probablement pas pertinent.

 # mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Sun Jun 21 18:04:33 2015 Raid Level : raid1 Array Size : 976629760 (931.39 GiB 1000.07 GB) Used Dev Size : 976629760 (931.39 GiB 1000.07 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Wed Jan 20 22:28:23 2016 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : bouzin:0 UUID : 102b07b8:703e4597:574b2ecf:880a1aee Events : 4349 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 1 8 33 1 active sync /dev/sdc1 # fdisk -l /dev/md0 Disk /dev/md0: 931.4 GiB, 1000068874240 bytes, 1953259520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x9c0ff432 # sfdisk -l /dev/md0 Disk /dev/md0: 244157440 cylinders, 2 heads, 4 sectors/track Units: cylinders of 4096 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/md0p1 0 - 0 0 0 Empty /dev/md0p2 0 - 0 0 0 Empty /dev/md0p3 0 - 0 0 0 Empty /dev/md0p4 0 - 0 0 0 Empty # sfdisk -l /dev/sda Disk /dev/sda: 121601 cylinders, 255 heads, 63 sectors/track Units: cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sda1 0+ 121601- 121602- 976760832 fd Linux raid autodetect /dev/sda2 0 - 0 0 0 Empty /dev/sda3 0 - 0 0 0 Empty /dev/sda4 0 - 0 0 0 Empty # sfdisk -l /dev/sdc Disk /dev/sdc: 121601 cylinders, 255 heads, 63 sectors/track Units: cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sdc1 0+ 121601- 121602- 976760832 fd Linux raid autodetect /dev/sdc2 0 - 0 0 0 Empty /dev/sdc3 0 - 0 0 0 Empty /dev/sdc4 0 - 0 0 0 Empty # cat /proc/mdstat Personalities : [raid1] md0 : active (auto-read-only) raid1 sda1[0] sdc1[1] 976629760 blocks super 1.2 [2/2] [UU] bitmap: 0/8 pages [0KB], 65536KB chunk 

Edit 8: le RAID est monté en lecture automatique uniquement. Contrairement à ce que j'ai écrit ici au début, je n'aurai pas à le mettre en lecture-écriture, il ira automatiquement en lecture-écriture si nécessaire, comme expliqué ici .

Le LVM

 # aptitude install lvm2 # pvscan No matching physical volumes found # lvscan No volume groups found 

Récupérer le file de configuration

Je n'ai pas de sauvegarde du file de configuration de lvm (je ne savais pas que j'en avais besoin).

Récupération de données à partir de partitions LVM RAID1 avec LiveCD Knoppix Linux .

L'idée est de lire le début de la partition LVM pour find le file de configuration LVM.

 # dd if=/dev/md0 bs=512 count=4096 skip=1 of=/tmp/md0-raw-start # vi /tmp/md0-raw-start 

Trouvez le file de configuration là-dedans. Débarrassez-vous des versions binarys et des anciennes versions de configuration.

Voici ce que je reçois (vg, lv, … sont en effet le nom que j'ai utilisé lors de la configuration du LVM):

 # Generated by LVM2 version 2.02.111(2) (2014-09-01): Sun Jun 21 18:12:39 2015 contents = "Text Format Volume Group" version = 1 description = "" creation_host = "bouzin" # Linux bouzin 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 creation_time = 1434910359 # Sun Jun 21 18:12:39 2015 vg { id = "Yxknle-OEes-hihh-tWCt-QBxC-JtP9-bl360E" seqno = 8 format = "lvm2" status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 8192 max_lv = 0 max_pv = 0 metadata_copys = 0 physical_volumes { pv0 { id = "gUyTdb-rc7j-rJh0-B2EZ-ebb7-mf77-KBgNWm" device = "/dev/md0" status = ["ALLOCATABLE"] flags = [] dev_size = 1953259520 pe_start = 2048 pe_count = 238434 } } logical_volumes { lv0 { id = "AwliYc-HczW-LZ1x-czpO-YZOJ-sr7k-T13HUf" status = ["READ", "WRITE", "VISIBLE"] flags = [] creation_host = "bouzin" creation_time = 1434910352 segment_count = 1 segment1 { start_extent = 0 extent_count = 953 type = "ssortingped" ssortingpe_count = 1 ssortingpes = [ "pv0", 0 ] } } lv1 { id = "Ec1tN2-WKaf-v2if-lAu2-MfiI-1hkE-XyKFGI" status = ["READ", "WRITE", "VISIBLE"] flags = [] creation_host = "bouzin" creation_time = 1434910359 segment_count = 1 segment1 { start_extent = 0 extent_count = 7152 type = "ssortingped" ssortingpe_count = 1 ssortingpes = [ "pv0", 953 ] } } lv2 { id = "gFWdEh-7HUJ-zwX1-nqEU-DomC-tdfW-ZGChNw" status = ["READ", "WRITE", "VISIBLE"] flags = [] creation_host = "bouzin" creation_time = 1434910366 segment_count = 1 segment1 { start_extent = 0 extent_count = 230329 type = "ssortingped" ssortingpe_count = 1 ssortingpes = [ "pv0", 8105 ] } } } } 

Cela confirme que j'ai installé les partitions dans cet ordre:

 swap / /home 

Edit 2: Note importante

Contrairement à ce qui est montré dans la page à laquelle je lier, ne manquez pas les quelques lignes avant vg { , en particulier le contents = ... , sinon vous obtiendrez

 `Can't process text format file - missing contents field.` 

erreur lors de l'utilisation de vgcfgrestore .

Utiliser le file de configuration récupéré

Installer le file de configuration récupéré dans le directory de configuration de lvm et démarrer lvm.

 # mkdir /etc/lvm/backup # cp /tmp/md0-raw-start /etc/lvm/backup/vg # systemctl start lvm2 # systemctl status lvm2 ● lvm2-activation.service - Activation of LVM2 logical volumes Loaded: loaded (/lib/systemd/system/lvm2-activation.service; enabled) Active: inactive (dead) since Thu 2016-01-21 20:37:42 UTC; 4s ago Docs: man:lvm(8) man:vgchange(8) Process: 22212 ExecStart=/sbin/lvm vgchange -aay --sysinit (code=exited, status=0/SUCCESS) Main PID: 22212 (code=exited, status=0/SUCCESS) Jan 21 20:37:42 debian lvm[22212]: No volume groups found 

Et voici le problème. No volume groups found .

 # vgscan Reading all physical volumes. This may take a while... No volume groups found 

Nan.

 # vgcfgrestore vg Couldn't find device with uuid gUyTdb-rc7j-rJh0-B2EZ-ebb7-mf77-KBgNWm. Cannot restore Volume Group vg with 1 PVs marked as missing. Restore failed. 

Depuis que j'ai identifié et corrigé des lignes manquantes dans mon file de configuration lvm récupéré (voir Edit 2 ci-dessus), ce message d'erreur de vgcfgrestore est plus explicite.

Pourtant, où est-ce que je vais d'ici?

Table de partition effacée?

Retour à la description du tableau:

 # file -s /dev/{md0,sda,sdc} /dev/md0: DOS/MBR boot sector /dev/sda: DOS/MBR boot sector /dev/sdc: DOS/MBR boot sector 

D' un autre post ici , je m'attendrais à quelque chose comme ça:

 $ file -s /dev/{sde1,md2} /dev/sde1: LVM2 (Linux Logical Volume Manager) , UUID: ZK8IfBzUHPH5befvm5CZ81oIXHm11TG /dev/md2: LVM2 (Linux Logical Volume Manager) , UUID: ZK8IfBzUHPH5befvm5CZ81oIXHm11TG 

Dernier démarrage avant ce problème, j'ai installé Linux Mint en utilisant une key USB sur une autre machine, en utilisant cette machine pour créer le lecteur de démarrage. J'ai copié le "hybride" .iso sur le bâton en utilisant dd puis eu des problèmes le formater à FAT32 en utilisant GParted. Je pense que j'ai essayé quelques fdisk puis finalement abandonné.

En y pensant, il est probable que j'ai foiré avec mon système en utilisant fdisk sur le mauvais /dev . Je ne peux pas me callbacker avec certitude ce que j'ai fait, mais ça pourrait être un indice. Je ne peux pas penser à autre chose. Le système est Debian Jessie avec des mises à jour sans surveillance, mais je ne pense pas qu'une mise à jour automatique a fait cela.

Notez que la partition commence avec le swap, donc l'effacement du début pourrait être less critique que s'il commençait avec des files importants.

Quelqu'un peut-il confirmer que DOS/MBR boot sector est le problème et pourrait être dû à une erreur de partitionnement de key USB?

Et le plus important, une idée comment résoudre ce problème?

(J'ai une sauvegarde quotidienne de la plupart des files importants sur le disque.Je voudrais résoudre ce problème pour la compréhension, et parce que je voudrais vérifier les files que je pourrais manquer des sauvegardes.)

Les instructions ici peuvent s'appliquer, mais j'apprécierais un peu plus de détails avant de procéder car il est un peu peu clair pour moi.

Édition 1: option Testdisk

Quelqu'un suggère d' abandonner la récupération de table de partition, mais en utilisant Testdisk pour récupérer datatables. Je pourrais essayer de sauvegarder datatables existantes de cette façon avant d'essayer quelque chose d'héroïque avec pvcreate .

FWIW, voici la sortie de Testdisk.

Une parsing

 Disk /dev/md0 - 1000 GB / 931 GiB - CHS 244157440 2 4 Current partition structure: Partition Start End Size in sectors No partition is bootable 

Recherche rapide

 Disk /dev/md0 - 1000 GB / 931 GiB - CHS 244157440 2 4 Partition Start End Size in sectors * Linux Swap 255 0 1 256 1 4 16 P Linux 976128 0 1 8299775 1 4 58589184 P Linux 8299776 0 1 244156671 1 4 1886855168 SWAP2 version 0, pagesize=8192, 8192 B ext4 blocksize=4096 Large file Sparse superblock, 29 GB / 27 GiB ext4 blocksize=4096 Large file Sparse superblock, 966 GB / 899 GiB 

Edit 2: option pvcreate

Voici à nouveau le message d'erreur.

 # vgcfgrestore vg Couldn't find device with uuid gUyTdb-rc7j-rJh0-B2EZ-ebb7-mf77-KBgNWm. 

Maintenant, suite à cette suggestion , devrais-je essayer cela?

 dd if=/dev/zero count=1 of=/dev/md0 pvcreate --uuid gUyTdb-rc7j-rJh0-B2EZ-ebb7-mf77-KBgNWm --norestorefile vcfgrestore 

Je suis sûr que c'est tout, mais j'apprécierais une confirmation.

Edit 3: Symptômes

J'ai oublié de mentionner les messages d'erreur que j'ai eu au démarrage.

Premier redémarrage, j'ai eu cette erreur:

 error: disk `lvmid/Yxknle-OEes-...` not found. Entering rescue mode... grub rescue> ls (hd0) (hdO,msdos1), (hd1) (hd1,msdos1) (hd2) (hd2,msdos2) (md/0) 

Ensuite, j'ai essayé de retirer un disque. Pas de changement. Puis l'autre et l'erreur ont changé et j'ai maintenant constamment cette nouvelle erreur:

 error: file `/boot/grub/i386-pc/normal.mod` not found. 

Edit 4: strace pvscan

 # strace -e trace=open pvscan 2>&1 | grep /dev/md open("/dev/md0", O_RDONLY|O_DIRECT|O_NOATIME) = 3 open("/dev/md0", O_RDONLY) = 5 open("/dev/md0", O_RDONLY) = 3 open("/dev/md0", O_RDONLY|O_DIRECT|O_NOATIME) = 3 open("/dev/md0", O_RDONLY|O_DIRECT|O_NOATIME) = 3 

Edit 5: file de sauvegarde lvm récupéré

En utilisant Testdisk, j'ai réussi à mettre la main sur /etc/lvm/backup/vg .

 # Generated by LVM2 version 2.02.111(2) (2014-09-01): Sun Jun 21 20:19:54 2015 contents = "Text Format Volume Group" version = 1 description = "Created *after* executing 'vgcfgbackup'" creation_host = "bouzin" # Linux bouzin 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 creation_time = 1434910794 # Sun Jun 21 20:19:54 2015 vg { id = "Yxknle-OEes-hihh-tWCt-QBxC-JtP9-bl360E" seqno = 8 format = "lvm2" # informational status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 8192 # 4 Megabytes max_lv = 0 max_pv = 0 metadata_copys = 0 physical_volumes { pv0 { id = "gUyTdb-rc7j-rJh0-B2EZ-ebb7-mf77-KBgNWm" device = "/dev/md0" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 1953259520 # 931,387 Gigabytes pe_start = 2048 pe_count = 238434 # 931,383 Gigabytes } } logical_volumes { lv0 { id = "AwliYc-HczW-LZ1x-czpO-YZOJ-sr7k-T13HUf" status = ["READ", "WRITE", "VISIBLE"] flags = [] creation_host = "bouzin" creation_time = 1434910352 # 2015-06-21 20:12:32 +0200 segment_count = 1 segment1 { start_extent = 0 extent_count = 953 # 3,72266 Gigabytes type = "ssortingped" ssortingpe_count = 1 # linear ssortingpes = [ "pv0", 0 ] } } lv1 { id = "Ec1tN2-WKaf-v2if-lAu2-MfiI-1hkE-XyKFGI" status = ["READ", "WRITE", "VISIBLE"] flags = [] creation_host = "bouzin" creation_time = 1434910359 # 2015-06-21 20:12:39 +0200 segment_count = 1 segment1 { start_extent = 0 extent_count = 7152 # 27,9375 Gigabytes type = "ssortingped" ssortingpe_count = 1 # linear ssortingpes = [ "pv0", 953 ] } } lv2 { id = "gFWdEh-7HUJ-zwX1-nqEU-DomC-tdfW-ZGChNw" status = ["READ", "WRITE", "VISIBLE"] flags = [] creation_host = "bouzin" creation_time = 1434910366 # 2015-06-21 20:12:46 +0200 segment_count = 1 segment1 { start_extent = 0 extent_count = 230329 # 899,723 Gigabytes type = "ssortingped" ssortingpe_count = 1 # linear ssortingpes = [ "pv0", 8105 ] } } } } 

Il est identique à ce que j'avais récupéré, sauf qu'il a des commentaires.

Modifier 6: essayer de créer un volume physique

D'après ci-dessus, la taille de /dev/md0 est de 976629760 kB.

 # dd if=/dev/md0 of=/media/user/bak/copy_lvm/start bs=1M count=1 # dd if=/dev/md0 of=/media/user/bak/copy_lvm/end bs=1M count=1 skip=953739 

(En espérant que j'utilise le dd correctement.)

Je ne sais pas comment je devrais utiliser pvcreate :

 # pvcreate --uuid gUyTdb-rc7j-rJh0-B2EZ-ebb7-mf77-KBgNWm --norestorefile Can only set uuid on one volume at once Run `pvcreate --help' for more information. # pvcreate --uuid gUyTdb-rc7j-rJh0-B2EZ-ebb7-mf77-KBgNWm --norestorefile /dev/md0 Can't open /dev/md0 exclusively. Mounted filesystem? 

J'ai essayé de mettre le tableau en lecture-écriture.

 # mdadm --readwrite /dev/md0 mdadm: failed to set writable for /dev/md0: Device or resource busy 

Je ne sais pas pourquoi c'est occupé. lsof ne cède rien.

 # lsof /dev/md0 

Edit 7: Testdisk à nouveau

Grâce à Testdisk, j'ai réussi à sauvegarder les files pour lesquels je n'avais pas de sauvegarde automatique. Je devrais être en security, maintenant. Il ne s'agit que de sauver le système pour éviter de le réinstaller à partir de zéro. (J'ai même copié / etc.)

Testdisk effectue également la détection de partition et la réparation de la table de partitions. Il a détecté mes partitions (voir ci-dessus) mais a indiqué que le swap était le bootable. J'ai changé cela en celui qui tient le système. Peut-être une certaine supercherie Testdisk s'est également produite derrière la scène. Quoi qu'il en soit, j'ai cliqué sur "Write", puis redémarré.

Toujours, même erreur au redémarrage:

 error: file `/boot/grub/i386-pc/normal.mod` not found. 

Cependant, il y a de bonnes nouvelles: le démarrage sur Debian Live, le tableau est automatiquement assemblé et le LVM reconnu. Je peux parcourir les partitions.

Je peux aussi vérifier que /boot/grub/i386-pc/normal.mod est là où il devrait être. (C'est binary donc je ne peux pas vérifier ce qu'il y a dedans.)

Oh, et j'ai aussi vérifié l'historique de bash de root, et je n'ai pas trouvé de command qui aurait causé ce désordre. J'ai utilisé fdisk sur /dev/sdh , mais pas sur /dev/sda ou /dev/sdc par erreur. Pourrait être avec GParted, cependant.

Edit 8: statut RAID et LVM

Depuis que les choses ont évolué, je pensais essayer ces commands à nouveau.

 # mdadm --examine /dev/md0 /dev/md0: MBR Magic : aa55 Partition[0] : 16 sectors at 2040 (type 82) Partition[1] : 58589184 sectors at 7809024 (type 83) Partition[2] : 1886855168 sectors at 66398208 (type 83) # file -s /dev/{md0,sda,sdc} /dev/md0: DOS/MBR boot sector; partition 1 : ID=0x82, start-CHS (0xff,0,1), end-CHS (0x10,1,4), startsector 2040, 16 sectors; partition 2 : ID=0x83, active, start-CHS (0x3ff,1,4), end-CHS (0x3ff,1,4), startsector 7809024, 58589184 sectors; partition 3 : ID=0x83, start-CHS (0x3ff,1,4), end-CHS (0x3ff,1,4), startsector 66398208, 1886855168 sectors /dev/sda: DOS/MBR boot sector /dev/sdc: DOS/MBR boot sector # mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Sun Jun 21 18:04:33 2015 Raid Level : raid1 Array Size : 976629760 (931.39 GiB 1000.07 GB) Used Dev Size : 976629760 (931.39 GiB 1000.07 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sat Jan 23 21:43:23 2016 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : bouzin:0 UUID : 102b07b8:703e4597:574b2ecf:880a1aee Events : 4355 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 1 8 33 1 active sync /dev/sdc1 # fdisk -l /dev/md0 Disk /dev/md0: 931.4 GiB, 1000068874240 bytes, 1953259520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x9c0ff432 Device Boot Start End Sectors Size Id Type /dev/md0p1 2040 2055 16 8K 82 Linux swap / Solaris /dev/md0p2 * 7809024 66398207 58589184 28G 83 Linux /dev/md0p3 66398208 1953253375 1886855168 899.7G 83 Linux # sfdisk -l /dev/md0 Disk /dev/md0: 244157440 cylinders, 2 heads, 4 sectors/track Units: cylinders of 4096 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/md0p1 255 256 2 8 82 Linux swap / Solaris /dev/md0p2 * 976128 8299775 7323648 29294592 83 Linux /dev/md0p3 8299776 244156671 235856896 943427584 83 Linux /dev/md0p4 0 - 0 0 0 Empty # cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sda1[0] sdc1[1] 976629760 blocks super 1.2 [2/2] [UU] bitmap: 0/8 pages [0KB], 65536KB chunk unused devices: <none> # vgscan Reading all physical volumes. This may take a while... No volume groups found 

Je pense que je commence à comprendre vos doutes. Tout se passe comme si le RAID ( /dev/md0 ) était partitionné sans LVM. Ce serait surprenant, cependant, comme je me souviens de la création du LVM et le file de configuration que j'ai trouvé le confirme.

Pourrait-il être Testdisk ignoré le LVM, puis écrit la table de partition directement dans /dev/md0 sorte de shunter le LVM (si cela a un sens)?

Edit 9: Où est mon LVM

FWIW, j'ai redémarré, toujours sur Debian Live et après l'installation de mdadm, le raid est automatiquement assemblé avant même l'installation de lvm2 (seulement liblvm2app2.2). Cela signifie-t-il que le LVM a «disparu»?

 # dmsetup ls No devices found # pvscan No matching physical volumes found # vgscan Reading all physical volumes. This may take a while... No volume groups found 

Edit 10: Réparation de grub

Supposons que le système de files / LVM fonctionne correctement et se concentrent sur l'erreur Grub.

Les conseils suivants sur Internet, j'ai essayé ce grub-install

 # mount /dev/md0p2 /mnt # grub-install --root-directory=/mnt /dev/md0 The file /mnt/boot/grub/stage1 not read correctly. 

La partition est reconnue comme Linux:

 # fdisk -l /dev/md0 Disk /dev/md0: 931.4 GiB, 1000068874240 bytes, 1953259520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x9c0ff432 Device Boot Start End Sectors Size Id Type /dev/md0p1 2040 2055 16 8K 82 Linux swap / Solaris /dev/md0p2 * 7809024 66398207 58589184 28G 83 Linux /dev/md0p3 66398208 1953253375 1886855168 899.7G 83 Linux 

Quelqu'un suggère que grub ne fonctionne que sur une taille d'inode de 128

 # tune2fs -l /dev/md0p2 | grep -i 'inode size' Inode size: 256 

Je ne vois pas de raison pour laquelle la taille de l'inode aurait changé, donc je ne suis pas sûr de m'en soucier.

Je suis coincé.

La table de partition indique une taille de swap étrange. Peut-être que j'ai foiré cette partition, la détection de Testdisk était incorrecte et elle a écrit la mauvaise table que nous voyons ici. Quoi qu'il en soit, ce n'est pas si mal. Je suppose que je peux toujours changer cela quand j'en ai besoin.

gparted montre ce qui suit:

 Partition File System Mount Point Size Flags /dev/md0p1 8 KiB unallocated unallocated 3.72 GiB /dev/md0p2 ext4 /mnt 27.94 GiB boot /dev/md0p3 ext4 899.72 GiB unallocated unallocated 3.72 GiB 

On dirait que la fin de ma partition / home / dev / md0p3 a été coupée.

Aucune mention au LVM.

Dois-je recréer / dev / md0p1 comme swap en ajoutant l'espace non alloué à proximité (et oublier les 4 Go perdus à la fin), ou jouer avec gparted ici ne fait qu'empirer les choses?

L'utilisation d'un LVM n'est pas d'un grand intérêt dans ce cas. Le disque de 1 To me permet de réserver un confortable 30 Go au système, dont seulement 5 Go sont utilisés. Cela ne me dérange pas de perdre le LVM dans le process à less que je me retrouve avec une configuration cassée.

Edit 11: Données sauvegardées, abandon du système de files

À ce stade, j'ai pu monter /home et etc et rsync sur un autre disque en gardant les permissions et tout, donc réinstaller à partir de zéro n'est pas vraiment un problème.

Je serais heureux si je comprenais ce qui se passait, mais perdre des heures à réparer le LVM pour finir avec une configuration que je ne comprendrais pas complètement et faire confiance n'est pas une bonne idée, alors j'ai décidé de réinstaller à partir de zéro.

Je pourrais réinstaller sur le tableau avec l'installateur Debian mais j'obtiendrais la même erreur au démarrage. J'ai dû lutter avec l'installateur pour détruire et recréer le tableau et finalement, tout s'est bien passé.

Une autre leçon apprise. A partir de maintenant, je ferai encore plus de sauvegardes. Pour sauvegarder /home , je le rsync sur un autre disque. Pour save /etc et la list des packages, voici ce que je fais au travail:

J'utilise etckeeper à la version /etc , puis je clone sur un autre lecteur. Et j'utilise apt-clone pour garder une list des packages installés.

 #!/bin/sh # # Script to clone installation # DEST_DIR=/mnt/backup_drive # Apt clone apt-clone clone $DEST_DIR/apt-clone/apt-clone-$(lsb_release -si)-$(lsb_release -sc)-$(lsb_release -sr)-$(date +%F).tar.gz # Git clone /etc cd $DEST_DIR/etc; git pull --quiet 

Votre information est contradictoire. /dev/md0 ne peut pas être simultanément un PV et avoir une table de partition. file reconnaîtrait un PV. Il semble que md0 soit partitionné de sorte que le volume LVM soit plutôt /dev/md0p1 ou /dev/md0p2 .

Peut-être pour une raison pvscan / vgscan ignorer /dev/md0 / /dev/md0p1 (et donc LVM ne peut pas find l'UUID). Vous pouvez exécuter pvscan travers strace afin de vérifier quels périphériques de bloc sont analysés:

 strace -e trace=open pvscan 2>&1 | grep /dev/md