/etc/crypttab не обновляется в initramfs

У меня новая установка Ubuntu 22.04 с полной шифрацией диска (LUKS) и ZFS, выбранная из опций установщика Ubuntu.

Мне нужно внести некоторые изменения в /etc/crypttab, чтобы разблокировка моих дисков происходила автоматически (роскошная автоматическая разблокировка USB), но изменения, которые я вношу в /etc/crypttab, не сохраняются в initramfs.

Что я делаю:

• Редактирую /etc/crypttab
• Запускаю update-initramfs -u
• Перезагружаю машину в систему, которая запрашивает пароль LUKS (initramfs)
• Проверяю содержимое /etc/, но crypttab отсутствует.

Я неправильно понимаю, как это работает? Мне нужно сохранить некоторую версию crypttab в загрузчике, но это не срабатывает.

Есть ли подсказки о том, что я делаю неправильно?

Я здесь, потому что столкнулся с той же проблемой, нашел этот вопрос через Google и хочу добавить некоторую информацию. Я пытаюсь автоматически разблокировать диск LUKS, не вводя пароль.

Сначала я отредактировал /etc/crypttab и изменил его запись на следующую:

sda3_crypt UUID=2d661ff8-d6a8-49c9-ae96-4d6e234bffe2 /dev/zero luks,discard,keyfile-size=32      

Затем я добавил новый ключ, используя следующую команду:

sudo cryptsetup luksAddKey --new-keyfile-size 32 /dev/sda3 /dev/zero

Наконец, я запустил update-initramfs, который выдал следующий вывод:

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.0.0-2-amd64
cryptsetup: WARNING: sda3_crypt: key file /dev/zero has insecure ownership, see 
    /usr/share/doc/cryptsetup/README.Debian.gz.
cryptsetup: WARNING: Skipping root target sda3_crypt: uses a key file

Это уже показалось подозрительным, но я все равно перезагрузил. К сожалению, эти действия сделали систему не загружаемой:

Gave up waiting for suspend/resume device
Gave up waiting for root file system device: Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/legend--vg-root does not exist. Dropping to a shell!


BusyBox v1.35.0 (Debian 1: 1.135.0-2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cat /etc/crypttab
cat: can't open '/etc/crypttab': No such file or directory

Я смог успешно загрузить систему снова, введя следующие команды в приглашении BusyBox:

cryptsetup luksOpen --key-file /dev/zero --keyfile-size 32 /dev/sda3 sda3_crypt
exit

Тем не менее, оригинальный вопрос остается: почему /etc/crypttab недоступен в initramfs?

Обновление

После дополнительного исследования я наконец могу ответить на исходный вопрос: /etc/crypttab отсутствует в initramfs, потому что скрипт разблокировки по умолчанию не использует это расположение; вместо этого он использует /cryptroot/crypttab.

Чтобы сделать /etc/crypttab доступным как /cryptroot/crypttab в initramfs, создайте следующий скрипт в каталоге /etc/initramfs-tools/hooks и сделайте его исполняемым:

#!/bin/sh
cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab"
exit 0

Наконец, стоит отметить, что использование автоматической разблокировки LUKS-устройств с пустыми паролями подрывает цель шифрования. Это так же небезопасно, как и отсутствие шифрования вообще.

Вместо того чтобы запускать sudo update-initramfs -u, запустите sudo update-initramfs -c -k all

Я столкнулся с этой проблемой после добавления нового диска nvme и его шифрования.

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

Мой зашифрованный раздел был на sda3, но поскольку я скопировал данные из предыдущей конфигурации с другой схемой разделов, мой /etc/crypttab выглядел так:

sda6_crypt UUID={uuid] none luks,discard

Похоже, что когда генерируется образ initramfs (как при установке нового ядра, так и при других обновлениях), несоответствие между именами в /etc/crypttab и фактическим разделом вызывает ошибку (которую, естественно, я не увидел), так что файл в initramfs (расположенный по адресу /cryptroot/crypttab) оказался пустым (0 байт). Эта нехватка файла и вызывает зависание процесса загрузки. Исправив /etc/crypttab на:

sda3_crypt UUID={uuid} none luks,discard

проблема решена. Конечно, если ваш initramfs уже поврежден, его нужно регенерировать:

sudo update-initramfs -u

Но будущие обновления должны пройти нормально.

Для меня (поскольку я уже сталкивался с проблемами) я сделал двойную проверку. (Это была Ubuntu 20.04, но ответ актуален и для 22.04)

После update-initramfs -c -k all я создал mkdir /tmp/x; cd /tmp/x; unmkinitramfs -v /boot/initrd.img-$(uname -r) . и проверил /tmp/x/main/cryptroot/crypttab. Он был пустым.

Решение для меня заключалось в редактировании /etc/cryptsetup-initramfs/conf-hook и создании шаблона ключевого файла. Моя окончательная конфигурация была:
KEYFILE_PATTERN=/etc/cryptsetup-keys.d/*.key в conf-hook и myroot UUID="8481c1f8-91d4-469d-9132-12d3948f503a" /etc/cryptsetup-keys.d/root.key luks,discard в /etc/crypttab. Ключ, без окончания новой строки, конечно, находился в /etc/cryptsetuyp-keys.d/root.key.

После этого, разархивировав initramfs, я увидел main/cryptroot/crypttab, который выглядел нормальным, и ключевой файл (с новым именем) был скопирован в main/cryptroot/keyfiles/myroot.key (“myroot” соответствует тому, что было в crypttab initramfs).

На моей системе (Ubuntu 22.04) все прошло, как ожидалось, когда я запустил следующие команды после редактирования /etc/crypttab:

sudo systemctl daemon-reload
sudo systemctl restart cryptsetup.target

Т.е. после добавления строки в crypttab я теперь вижу:

• новое расшифрованное устройство в /dev/mapper/
• изменения также сохраняются после перезагрузки

apt-get install cryptsetup-initramfs

По каким-то причинам на моей установке /usr/sbin/cryptsetup был присутствующим, но dpkg -S показал, что он не принадлежит никакому пакету (возможно, его установил установщик Live?). Но без cryptsetup-initramfs, mkinitramfs и update-initramfs не установят cryptsetup в initrd.

Спасибо всем за очень полезные ответы. Я недавно обновился до Ubuntu 24.04 и сломал свою загрузку. После дня и половины попыток исправить это, я решил создать резервную копию и перейти на Mint 22. Я столкнулся с той же проблемой, повторно используя свою схему разделов из Ubuntu до 24.x.

После чтения этого поста и нескольких попыток я обнаружил, что добавление опции ‘initramfs’ в файл crypttab для моего загрузочного раздела позволило update-initramsfs включить записи, необходимые для правильной загрузки с запросом на разблокировку дисков.

Это сработало для Linux Mint 22. Завтра я снова попытаюсь для Ubuntu 24.04 на моем резервном диске, чтобы увидеть, сработает ли это и там. Я верю, что должно, так как Mint основан на Ubuntu.