У меня есть Debian 8 VPS с зашифрованным корневым разделом. После обновления ядра несколько месяцев назад (версия пакета 3.2.73-2 + deb7u3) оно перестало правильно расшифровывать при загрузке. Насколько я могу судить, initramfs не загружал библиотеки криптографии и поэтому не знал, что делать.
Я нашел этот ответ, но это не решило проблемы, независимо от того, какой UUID мы пробовали. https://unix.stackexchange.com/questions/107810/why-my-encrypted-lvm-volume-luks-device-wont-mount-at-boot-time
Наш текущий кладж, который позволяет нам загружаться с ошибками, - это создание файла cryptroot в /etc/initramfs-tools/conf.d/cryptroot с содержимым
CRYPTOPTS=target=root,source=/dev/vda5,lvm=cloud--vg-root
и / etc / crypttab с содержимым
# <target name> <source device> <key file> <option>
crypt-vda5 /dev/vda5 none luks
Во время загрузки он запрашивает пароль и монтирует vg-root, а затем снова запрашивает пароль и жалуется, что раздел уже смонтирован, и выдает кучу ошибок, которые я должен нажать esc неоднократно, чтобы пройти. Если мы удалим один из этих файлов или изменим их, он не запрашивает пароль при загрузке, и, таким образом, монтировать root не удастся.
Есть идеи, как удалить клудж и исправить это навсегда?
Спасибо!
Это может сработать, если вы добавите следующее в /etc/initramfs-tools/initramfs.conf и двигаться /etc/initramfs-tools/conf.d/cryptroot с дороги.
CRYPTSETUP=Y
Затем перестройте initramfs, запустите его с параметрами -k и -v, которые покажут вам, что он делает, и добавляет ли он поддержку шифрования. Параметр -k сохранит временный каталог mkinitramfs, который используется, что может помочь в расследовании того, что происходит. Конечно, храните копию старых initramfs, чтобы вы могли их загрузить при необходимости.
Также / и т.д. / crypttab должен содержать имя логического тома, если это vg-root вместо crypt-vda5, обязательно замените его. Это имя является строкой example-name, используемой в следующем:
cryptsetup -v luksOpen /dev/vda5 example-name
Который должен быть доступен в:
/dev/mapper/example-name