Как восстановить раздел LUKS после неудачной операции изменения размера?
TL; DR: Я испортил операцию изменения размера раздела LUKS, и мне нужна помощь в его восстановлении. Ниже приведена вся соответствующая информация, о которой я мог подумать. Если вы считаете, что любая другая информация может иметь отношение к делу или что-то неясно, дайте мне знать.
Продолжение моего другого (самозакрытого) вопроса
Проблема
Не удается смонтировать зашифрованный раздел LUKS из-за (по крайней мере) того, что его ' физический размер отличается от размера его файловой системы, после неудачной попытки сжать раздел в соответствии с этим руководством
Решение
Я думаю (хотя бы частичное) Решение состоит в том, чтобы гарантировать, что размеры файловой системы и LV равны, и что размер PV больше, чем оба.
Предположение об отсутствии потери данных
Пожалуйста, исправьте меня, если я ошибаюсь. Потеря данных составляет от 0 до 62,14 ГБ, поскольку LVM на 62,14 ГБ меньше файловой системы. Если мне очень повезет, то ни в одном из уменьшенных блоков нет данных, если мне очень не повезет, то все они есть.
Вопрос и подвопросы
Может ли кто-нибудь помочь мне понять правильный и безопасный способ восстановить доступ к содержимому моего зашифрованного LUKS-раздела? Я не хочу понимать, что я делаю, и быть уверенным, что больше ничего не испорчу, пока не сделаю что-нибудь еще.
Прежде всего, я не уверен, смогу ли я вообще использовать шаги руководства с моей текущей отправной точкой, поскольку он, вероятно, ожидает начала функционального раздела LUKS. Это размеры разных устройств.
PV Size 900.00 GiB / not usable 3.00 MiB # pvdisplay
LV Size 842.62 GiB # lvdisplay
Filesystem 904.75331584 GB # disks
Filesystem 241858560 blocks # e2fsck
Physical 220887040 blocks # e2fsck
здесь здесь говорится, что файловая система и логический том должны иметь одинаковый размер, а здравый смысл говорит мне, что физический том должен быть большего или равного размера. Здесь ни один из этих случаев не подходит, поэтому мне нужно либо уменьшить файловую систему до LV (842,62 ГБ), либо увеличить LV до 904,75331584 ГБ и увеличить PV где-то выше этого.
- Все еще диски утверждают, что LUKS - 999 ГБ. Зачем?
- Лучше просто уменьшить файловую систему или увеличить как PV, так и LV?
- Если последнее, имеет ли значение порядок?
- Почему диски / pvdisplay и e2fsck расходятся во мнениях относительно размера PV и файловой системы? (241858560/220887040! = 904.75331584 / 900.00)
Статус-кво (снимки экрана и выходы различных команд)
Выходы команд
ubuntu@ubuntu:~$ sudo e2fsck -f /dev/mapper/ubuntu--vg-root
e2fsck 1.43.5 (04-Aug-2017)
The filesystem size (according to the superblock) is 241858560 blocks
The physical size of the device is 220887040 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes
ubuntu@ubuntu:~$ sudo mount /dev/ubuntu-vg/root /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/ubuntu--vg-root, missing codepage or helper program, or other error.
ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name /dev/mapper/crypt1
VG Name ubuntu-vg
PV Size 900.00 GiB / not usable 3.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 230399
Free PE 14561
Allocated PE 215838
PV UUID K3BIz8-FXNn-FYTU-jap6-Ri5X-Ilfq-ZLrwjk
ubuntu@ubuntu:~$ sudo lvdisplay
--- Logical volume ---
LV Path /dev/ubuntu-vg/root
LV Name root
VG Name ubuntu-vg
LV UUID HxqT5o-zJUq-RVBA-D8v2-YqpS-D685-FkvAbx
LV Write Access read/write
LV Creation host, time ubuntu, 2017-11-15 17:38:16 +0000
LV Status available
# open 0
LV Size 842.62 GiB
Current LE 215710
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1
--- Logical volume ---
LV Path /dev/ubuntu-vg/swap_1
LV Name swap_1
VG Name ubuntu-vg
LV UUID ybnQLA-5CKp-W2JS-62At-94kE-i8iT-jkrqx1
LV Write Access read/write
LV Creation host, time ubuntu, 2017-12-29 20:44:49 +0000
LV Status available
# open 0
LV Size 512.00 MiB
Current LE 128
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2
ubuntu@ubuntu:~$ sudo resize2fs -p /dev/mapper/ubuntu--vg-root
resize2fs 1.43.5 (04-Aug-2017)
Please run 'e2fsck -f /dev/mapper/ubuntu--vg-root' first.
Скриншоты
Жесткий диск до разблокировки crypt
Жесткий диск после разблокировки crypt
Корневой раздел после разблокировки cry
Замена раздела после разблокировки crypt
Что я сделал / причина проблемы
Я следовал руководству, но не сохранил журнал bash. Изучая руководство, это, вероятно, те команды, которые я выполнил.
# install requirements
sudo apt-get update && sudo apt-get install lvm2 cryptsetup
# unlock encrypted partition
sudo modprobe dm-crypt
sudo cryptsetup luksOpen /dev/sda3 crypt1
sudo vgscan --mknodes
sudo vgchange -ay
# check that all is ok
sudo e2fsck -f /dev/mapper/ubuntu--vg-root # no problem
# no problem!
# resize file system
sudo resize2fs -p /dev/mapper/ubuntu--vg-root <900-ish>g
# check that everything is still ok
sudo e2fsck -f /dev/mapper/ubuntu--vg-root
# no problem!
# display LVMs
sudo lvdisplay
# 'Note how much you need to reduce your root (LVM) Logical Volume by'
# I stupidly didn't understand what I should take note of, and hoped it wouldn't matter
# shrink the LVM
# guide says 'ubuntu--vg' in the guide, but only 'ubuntu-vg' existed for me
sudo lvreduce -L -80G /dev/ubuntu-vg/root
# show size of physical volume
sudo pvdisplay
# delete the swap partition (may have run with sudo, not sure)
lvremove /dev/ubuntu-vg/swap_1
# change physical size
sudo pvresize --setphysicalvolumesize <900-ish>G /dev/mapper/crypt1
# set permissions of LVM
sudo pvchange -x y /dev/mapper/crypt1
# create new swap partition (either 'ubuntu--vg' or 'ubuntu-vg', not sure)
sudo lvcreate -L 512m -n swap_1 ubuntu--vg
sudo mkswap -L swap_1 /dev/ubuntu-vg/swap_1
# mount the LVM
sudo mount /dev/ubuntu-vg/root /mnt
# fail!