Чому мій зашифрований об'єм LVM (пристрій LUKS) під час завантаження не монтується?

Я намагаюся налаштувати зашифрований том відповідно до цього посібника

Все налаштовано, але встановлення зашифрованого тома виходить з ладу під час завантаження з помилкою:

fsck.ext4: Немає такого файлу чи каталогу під час спроби відкрити / dev / mapper / safe_vault Можливо, неіснуючий пристрій?

Це моя установка:

криптовалюта

$ sudo cat /etc/crypttab
safe_vault  /dev/disk/by-uuid/d266ae14-955e-4ee4-9612-326dd09a463b  none    luks

ПРИМІТКА:

uuidПриходить від:

$ sudo blkid /dev/mapper/<my_logical_group>-safe_vault 
/dev/mapper/<my_logical_group>-safe_vault: UUID="d266ae14-955e-4ee4-9612-326dd09a463b" TYPE="crypto_LUKS" 

fstab

$ sudo cat /etc/fstab | grep safe_vault
/dev/mapper/safe_vault      /safe-vault     ext4    defaults    0 2

Що я зробив...

Тож я зайшов на веб-сайт преданника, і в поширених питаннях про них кажуть:

Переконайтеся, що у вашому ядрі є картограф пристрою та цільова крипта. Вихідні дані "dmsetup target" повинні містити перелік "криптовалют". Якщо його немає або команда не вдається, додайте до ядра картограф пристрою та криптовалюту.

Так я і, виявляється, у мене немає cryptмети:

$ sudo dmsetup targets
striped          v1.4.1
linear           v1.1.1
error            v1.0.1

Проблема в тому, що я не знаю, як додати таку ціль.

Я думаю, що це (не маючи cryptцілі), можливо, спричиняє crypttabігнорування конфігурації під час завантаження, і, таким чином, намагається встановити запис fstabне вдається, тому cryptsetupщо не відобразив мій зашифрований том на/dev/mapper/safe_vault .

ПРИМІТКА:

Зашифрований том можна успішно вручну відобразити, змонтувати та записати:

$ sudo cryptsetup luksOpen /dev/mapper/<my_logical_group>-safe_vault safe_vault
Enter passphrase for /dev/mapper/<my_logical_group>-safe_vault: 

$ sudo mount /dev/mapper/safe_vault /safe_vault

Ось як це виглядає після відображення та монтажу:

$ sudo lsblk -o name,uuid,mountpoint
NAME                                  UUID                                   MOUNTPOINT
sda                                                                          
├─sda1                                28920b00-58d3-4941-889f-6249357c56ee   
├─sda2                                                                       
└─sda5                                uhBLE7-Kcfe-RMi6-wrlX-xgVh-JfAc-PiXmBe 
  ├─<my_logical_group>-root (dm-0)       1bed9027-3cf7-4f8d-abdb-28cf448fb426   /
  ├─<my_logical_group>-swap_1 (dm-1)     a40c16c4-7d0c-46d7-afc8-99ab173c20bb   [SWAP]
  ├─<my_logical_group>-home (dm-2)       e458abb7-b263-452d-8670-814fa737f464   /home
  ├─<my_logical_group>-other (dm-3)      0a1eec42-6534-46e1-8eab-793d6f8e1003   /other
  └─<my_logical_group>-safe_vault (dm-4) d266ae14-955e-4ee4-9612-326dd09a463b   
    └─safe_vault (dm-5)               9bbf9f47-8ad8-43d5-9c4c-dca033ba5925   /safe-vault
sr0  

ОНОВЛЕННЯ

• Виявляється, у мене є cryptціль, але для того, щоб проявити її, dmsetup targetsмені довелося спочаткуcryptsetup luksOpen <my-device>
• Я спробував з допомогою UUIDS замість згідно @Mikhail Morfikov в відповідь , але він по- , як і раніше не вдається під час завантаження.

Я все ще думаю, що проблема полягає в тому, що якось зашифрований том не відображається (відкривається з cryptsetup luksOpen) під час завантаження, таким чином, його немає /dev/mapper/<safe_vault or UUID>, тоді спроба встановити його (fstab) не вдається.

ОНОВЛЕННЯ 2

Виявляється, у мене не було необхідних сценаріїв для монтажу під час завантаження. Дивіться примітку у відповіді @ Михайла Морфікова.

Ви повинні звернути увагу на UUID. Наприклад, це моя конфігурація:

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi
│   ├─debian_crypt-swap (dm-1) 3f9f24d7-86d1-4e21-93e9-f3c181d05cf0   [SWAP]
│   ├─debian_crypt-tmp (dm-2)  93fc8219-f985-45fb-bd5c-2c7940a7512d   /tmp
│   ├─debian_crypt-home (dm-3) 12e8566c-8f0f-45ec-8524-6d9d9ee91eae   /home
│   └─debian_crypt-root (dm-4) 9685570b-4c9e-43ea-815e-49d10dc7a1bf   /

У мене є один зашифрований розділ (sda2) з 4 томами (LVM). Що мені потрібно - це встановити два UUID в потрібних файлах. Переходить до UUID sda2, /etc/crypttabа об'єм UUID (наприклад, debian_crypt-root) переходить до/etc/fstab .

Отже, це було б:

# cat /etc/crypttab
sda2_crypt              UUID=727fa348-8804-4773-ae3d-f3e176d12dac   none        luks

# cat /etc/fstab
UUID=9685570b-4c9e-43ea-815e-49d10dc7a1bf       /               ext4    defaults,errors=remount-ro              0 1

Після зміни /etc/crypttabфайлу вам доведеться відновити initramfs:

# update-initramfs -u -k all

ПРИМІТКА

Пакет cryptsetupповинен бути встановлений, оскільки він має сценарії запуску, які забезпечують підтримку автоматичного налаштування зашифрованих томів під час завантаження.

Навіщо турбуватися згадувати це? Ну, якщо налаштувати LVM під час установки Debian свистячих встановлює пакети Cryptsetup-бен , libcryptsetup4і , lvm2але не cryptsetup, таким чином , у вас є інструменти для настройки LVM і LUKS пристроїв , але не скрипти необхідно змонтувати lüks пристроїв під час завантаження. Ті приходять у пакеті cryptsetup .

Здається , що @Mikhail Morfikov в відповідь кришки кріплення під час initramfs стадії. Альтернатива (якщо це не коренева файлова система) - розшифрувати та змонтувати розділ автоматично через systemd , після завантаження ядра linuz. Звичайно, це можливо лише в тому випадку, якщо ви працюєте systemd . Я поясню тут метод:

/etc/crypttabзапис:

crypt2 UUID=e412-blahblah /path/to/crypt2.key luks,noauto

Ось noautoінструкція не намагатися розшифрувати диск на етапі initramfs .

Вище e412-blahblahє UUID розділу, що містить систему luks, у моєму випадку розділ /dev/sdb2:

# blkid | grep sdb2
/dev/sdb2: UUID="e41274d8-fd83-4632-b560-ad0ba113ae75" TYPE="crypto_LUKS" PARTUUID="5673a908-02"

Під час запуску ядра linuz systemd прочитає /etc/crypttabфайл та створить службовий файл часу виконання /run/systemd/generator/systemd-cryptsetup@crypt2.service. Однак ця служба не запускається автоматично. Ви можете запустити його вручну

systemctl start systemd-cryptsetup@crypt2.service

але розшифрувати його та встановити під час запуску /etc/fstab може знадобитися наступне:

/dev/mapper/crypt2--vg-data /media/crypt-data ext4 defaults,noauto,user,x-systemd.automount,x-systemd.requires=systemd-cryptsetup@crypt2.service 0 2

Ось x-systemd.automountінструкція до систематизації монтажу /media/crypt-data, і x-systemd.requires=systemd-cryptsetup@crypt2.serviceце інструкція для систематизації, що розшифрування crypt2потрібне, перш ніж це можливо.

В systemd фактично не змонтується каталог до першого доступу до нього, наприклад ls /media/crypt-data, тоді він змонтується просто вчасно та з’явиться після цього у /proc/mounts.

Пов'язані

Ви можете запитати "* навіщо мати зашифрований диск даних з ключем у кореневій файловій системі?". Це тому, що коренева файлова система також зашифрована, тому ключ безпечний. Коренева файлова система розшифровується під час initramfs , відповідь а-ля Михайла. У мене є ще один запис у /etc/crypttabфайлі для цього:

crypt1 UUID=8cda-blahbalh none luks,discard,lvm=crypt1--vg-root

і я описую налаштування цього та bob usb тут