После сбоя питания жесткий диск Ubuntu 10.04 Server больше не загружается. Я пробовал использовать boot-repair но он не мог найти операционную систему.
Я запустил gdisk, чтобы проверить, где находится раздел lvm и что он все еще в рабочем состоянии. Вот результат:
GPT fdisk (gdisk) version 0.6.14
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3A0E99EE-74F9-41F5-81A0-7B7D7235DE8E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2157 sectors (1.1 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02
2 4096 503807 244.0 MiB EF00
3 503808 3907028991 1.8 TiB 8E00
Command (? for help): i
Partition number (1-3): 3
Partition GUID code: E6D6D379-F507-44C2-A23C-238F2A3DF928 (Linux LVM)
Partition unique GUID: 4F35492A-C6DD-4E31-9D53-8C88A74A1B48
First sector: 503808 (at 246.0 MiB)
Last sector: 3907028991 (at 1.8 TiB)
Partition size: 3906525184 sectors (1.8 TiB)
Attribute flags: 0000000000000000
Partition name:
Итак, он все еще там и, по-видимому, в рабочем состоянии, поэтому я продолжил сканирование vgscan:
: / # vgscan
Reading all physical volumes. This may take a while... Found volume group "ubuntu" using metadata type lvm2
Так я и сделал : / # vgchange -ay убунту с последующим : / # lvs и получил:
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
root ubuntu -wi-ao 4.40g
swap_1 ubuntu -wi-a- 260.00m
Дело в том, что там должен быть еще один VG размером почти 1,8 ТБ, но он не отображается.
Итак .. есть ли способ восстановить LV, который не отображается для lvs? Мне нужно восстановить там 1 важный файл, который был создан после создания последней резервной копии.
: / # vgdisplay
--- Volume group ---
VG Name ubuntu
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 1.82 TiB
PE Size 4.00 MiB
Total PE 476870
Alloc PE / Size 1191 / 4.65 GiB
Free PE / Size 475679 / 1.81 TiB
VG UUID r3Z9Io-bWk7-i7wp-9QGZ-mF3o-ucQs-SdsaGW
Я не понимаю, не хватает ли вам сейчас одного LV 1,8 ТБ или PV + VG + LV 1,8 ТБ. Если LV был расположен в другом VG, то лучше всего попытаться найти недостающий диск, начиная с pvscan. Например, у вас может быть проблема с фильтром lvm или кешем. Многие дистрибутивы пытаются сильно навредить вам, добавляя lvm.conf в initrd, но не сообщают, что вам нужно будет перестроить его, если вы измените его позже. Вы можете запустить pvscan -vvv и посмотреть, говорит ли что-нибудь о «игнорируется фильтрацией».
Если вы только что потеряли LV из конфигурации, то вопрос в том, как это произошло и можно ли его прочитать. Таким образом, тестовый dd с диска в / dev / null может быть хорошей отправной точкой, то есть посмотреть, можете ли вы прочитать «круговое движение, где находился старый LV»
Обычно я сначала снова успешно загружаю систему, комментируя затронутый LV в fstab.
В крайнем случае, вы можете найти на вашем диске последние резервные копии конфигурации LVM. Его можно прочитать, используя что-то вроде dd + strings + grep -A1000 "LVM". Но вы еще не так потерялись :) На основе этой конфигурации можно воссоздать старые состояния конфигурации LVM на диск. Но прежде чем это сделать, вы должны четко понимать, что именно повреждено, и я бы протестировал все это на копии поврежденного диска, а не на исходном.