Восстановить LVM (на RAID1): групп томов не найдено. Таблица разделов стирается?

Я пытаюсь восстановить LVM (без шифрования) на RAID1, используя Debian Live.

По-видимому, RAID1 можно собрать без проблем, но LVM сломан. Вы можете перейти в раздел LVM. Часть RAID остается на случай, если это будет иметь значение.

Рейд

# 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: 

Вот 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 

Я боюсь, что этот 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 : 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 

Редактирование 8: RAID монтируется автоматически для чтения. В отличие от того, что я написал здесь вначале, мне не придется устанавливать его для чтения-записи, он будет автоматически читать и записывать, когда это необходимо, как объясняется здесь .

LVM

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

Восстановить файл конфигурации

У меня нет резервной копии конфигурационного файла lvm (я не знал, что мне нужно).

После восстановления данных из RAID1 разделов LVM с помощью Knoppix Linux LiveCD .

Идея состоит в том, чтобы прочитать начало раздела LVM, чтобы найти файл конфигурации LVM.

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

Найдите там конфигурационный файл. Избавьтесь от бинарных и старых конфигурационных версий.

Вот что я получаю (vg, lv, … действительно имя, которое я использовал при настройке 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_copies = 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 = "striped" stripe_count = 1 stripes = [ "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 = "striped" stripe_count = 1 stripes = [ "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 = "striped" stripe_count = 1 stripes = [ "pv0", 8105 ] } } } } 

Это подтверждает, что я настраиваю разделы в следующем порядке:

 swap / /home 

Редактировать 2: Важное примечание

В отличие от того, что показано на странице, на которую я ссылаюсь, не пропустите несколько строк перед vg { , особенно contents = ... , иначе вы получите

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

ошибка при использовании vgcfgrestore .

Использовать восстановленный файл конфигурации

Установите восстановленный файл конфигурации в каталог конфигурации lvm и запустите 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 

И вот проблема. No volume groups found .

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

Неа.

 # 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. 

Поскольку я идентифицировал и исправил недостающие строки в восстановленном конфигурационном файле lvm (см. Редактировать 2 выше), это сообщение об ошибке из vgcfgrestore более явное.

И все же, куда я иду отсюда?

Таблица разделов стирается?

Вернуться к описанию массива:

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

Из другого поста здесь я бы ожидал чего-то вроде этого:

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

Последняя загрузка перед этой проблемой, я установил Linux Mint с помощью USB-накопителя на другой машине, используя этот аппарат для создания загрузочного диска. Я скопировал «гибрид» .iso на палочке, используя dd тогда возникли проблемы с его возвратом в FAT32 с использованием GParted. Кажется, я попробовал несколько fdisk затем сдался.

Думая об этом, я, скорее всего, испортил свою систему, используя fdisk на неправильном /dev . Я не могу точно помнить, что я сделал, но это может быть ключом. Я ничего не могу придумать. Система – Debian Jessie с автоматическими обновлениями, но я не думаю, что автоматическое обновление сделало это.

Обратите внимание, что раздел начинается с swap, поэтому стирание начала может быть менее критичным, чем если бы оно начиналось с важных файлов.

Может ли кто-нибудь подтвердить, что DOS/MBR boot sector является проблемой, и может быть из-за ошибки разбиения USB-диска?

И самое главное, любая идея, как это исправить?

(У меня есть ежедневная резервная копия большинства важных файлов на диске. Я бы хотел решить это ради понимания, и потому что я хочу проверить файлы, на которые я могу пропустить резервные копии.)

Здесь могут быть инструкции, но я хотел бы получить более подробную информацию, прежде чем продолжить, поскольку для меня это немного непонятно.

Изменить 1: вариант Testdisk

Кто-то предлагает отказаться от восстановления таблицы разделов, но с помощью Testdisk для восстановления данных. Я мог бы попытаться сделать резервную копию существующих данных таким образом, прежде чем попробовать что-нибудь героическое в pvcreate .

FWIW, вот вывод Testdisk.

Анализ

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

Быстрый поиск

 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 

Изменить вариант 2: pvcreate

Вот сообщение об ошибке снова.

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

Теперь, следуя этому предложению , я должен попробовать это?

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

Я почти уверен, что это так, но я был бы признателен за подтверждение.

Редактировать 3: Симптомы

Я забыл упомянуть сообщения об ошибках, которые я получил при запуске.

Первая перезагрузка, у меня была эта ошибка:

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

Затем я попытался удалить один диск. Без изменений. Затем другая и ошибка изменились, и теперь у меня есть эта новая ошибка:

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

Редактировать 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 

Редактирование файла резервной копии 5: lvm

Используя Testdisk, мне удалось получить /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_copies = 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 = "striped" stripe_count = 1 # linear stripes = [ "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 = "striped" stripe_count = 1 # linear stripes = [ "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 = "striped" stripe_count = 1 # linear stripes = [ "pv0", 8105 ] } } } } 

Он идентичен тому, что я восстановил, кроме комментариев.

Редактирование 6: попытка создания физического тома

Сверху размер /dev/md0 составляет 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 

(Надеюсь, я правильно использую dd .)

Не знаю, как я должен использовать 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? 

Я попытался настроить чтение и запись массива.

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

Я не знаю, почему он занят. lsof ничего не дает.

 # lsof /dev/md0 

Редактировать 7: Testdisk снова

Благодаря Testdisk мне удалось создать резервную копию файлов, для которых у меня не было автоматического резервного копирования. Теперь я должен быть в безопасности. Речь идет только о сохранении системы, чтобы избежать переустановки с нуля. (Я даже скопировал / и т. Д.)

Testdisk также выполняет разделение и восстановление таблицы разделов. Он обнаружил мои разделы (см. Выше), но указал, что обмен был загрузочным. Я изменил это на тот, который держит систему. Возможно, за сценой произошло и трюк Testdisk. Во всяком случае, я нажал «Write», а затем перезагрузился.

Тем не менее, такая же ошибка при перезагрузке:

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

Однако есть хорошие новости: загрузка в Debian Live, массив автоматически собирается и LVM распознается. Я могу просматривать разделы.

Я также могу проверить, что /boot/grub/i386-pc/normal.mod , где он должен быть. (Это двоично, поэтому я не могу проверить, что в нем).

О, и я также проверил историю bash bash, и я не нашел команду, которая вызвала бы этот беспорядок. Я использовал fdisk на /dev/sdh , но не по ошибке /dev/sda или /dev/sdc по ошибке. Однако может быть с GParted.

Изменить 8: состояние RAID и LVM

Поскольку все сложилось, я подумал, что снова попробую эти команды.

 # 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 

Кажется, я начинаю понимать ваши сомнения. Все выглядит так: RAID ( /dev/md0 ) разделен без LVM. Это было бы удивительно, хотя, как я помню, создание LVM и файла конфигурации, который я нашел, подтверждает это.

Может быть, Testdisk проигнорировал LVM, а затем написал таблицу разделов прямо в /dev/md0 вроде шунтирования LVM (если это имеет смысл)?

Редактировать 9: Где мой LVM

FWIW, я перезагрузился, все еще на Debian Live и после установки mdadm, рейд автоматически собирается даже до установки lvm2 (только liblvm2app2.2 есть). Означает ли это, что LVM «исчез»?

 # 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 

Редактировать 10: Ремонт Grub

Предположим, что файловая система / LVM работает правильно и сосредоточена на ошибке Grub.

Следуя советам в Интернете, я попробовал эту grub-install

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

Раздел распознается как 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 

Кто-то предполагает, что grub работает только с размером inode 128

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

Я не вижу причин, по которым размер inode изменился, поэтому я не уверен, что мне все равно.

Я застрял.

Таблица разделов указывает на странный размер подкачки. Возможно, я испортил этот раздел, обнаружение из Testdisk было неправильным, и оно написало неверную таблицу, которую мы видим здесь. Во всяком случае, это не так уж плохо. Думаю, я всегда могу изменить это, когда мне нужно.

gparted показывает следующее:

 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 

Похоже, что конец моего / домашнего раздела (/ dev / md0p3) был сокращен.

Не упоминается LVM.

Должен ли я воссоздать / dev / md0p1 в качестве свопа, добавляя незанятое пространство рядом с ним (и забыть о 4 ГБ, потерянных в конце), или играя с gparted здесь, только ухудшают ситуацию?

Использование LVM не представляет большого интереса в этом случае. 1 ТБ диск позволяет мне зарезервировать 30 ГБ для системы, только 5 ГБ которой используется. Я не против потери LVM в этом процессе, если я не закончил сломанную настройку.

Редактирование 11: сохраненные данные, отказ от файловой системы

На этом этапе мне удалось смонтировать /home и etc И rsync чтобы на другом диске сохранялись разрешения и все, поэтому переустановка с нуля – это не проблема.

Я был бы рад, если бы я понял, что произошло, но потеряв часы, исправляя LVM, чтобы закончить настройку, которую я бы не понял полностью, и доверие – это не отличный шаг, поэтому я решил переустановить с нуля.

Я мог бы переустановить в массиве с установщиком Debian, но я бы получил ту же ошибку при загрузке. Мне пришлось бороться с установщиком, чтобы уничтожить и воссоздать массив, и в конечном итоге все прошло хорошо.

Еще один урок. С этого момента я сделаю еще больше резервных копий. Чтобы создать резервную копию /home , я rsync его на другой диск. Чтобы сохранить /etc и список пакетов, вот что я делаю на работе:

Я использую etckeeper для версии /etc , затем я клонирую его на другой диск. И я использую apt-clone для хранения списка установленных пакетов.

 #!/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 

Ваша информация противоречива. /dev/md0 не может одновременно быть PV и иметь таблицу разделов. file распознает PV. Кажется, что md0 разделено так, что объем LVM скорее /dev/md0p1 или /dev/md0p2 .

Может быть, по какой-то причине pvscan / vgscan игнорировать /dev/md0 / /dev/md0p1 (и, следовательно, LVM не может найти UUID). Вы можете запустить pvscan через strace , чтобы проверить, какие блочные устройства сканируются:

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