24.10 /etc/crypttab не разблокирует диски при загрузке с конфигурацией, работающей на 1000%

После чистой установки 24.10 я перенёс свою конфигурацию, которая работала много лет. Эта конфигурация работала нормально на 22.04 до этого. Я использовал nofail только в последнем столбце.

/etc/crypttab

dm_crypt-0 UUID=1234 none luks

sea4tb  UUID=1234  /etc/luks-keys/sea4tb  luks,nofail,timeout=10s
wd4tb   UUID=1234  /etc/luks-keys/sea4tb  luks,nofail,timeout=10s
8tb     UUID=1234  /etc/luks-keys/sea4tb  luks,nofail,timeout=10s
2tb     UUID=1234  /etc/luks-keys/sea4tb  luks,nofail,timeout=10s
2tbb    UUID=1234  /etc/luks-keys/sea4tb  luks,nofail,timeout=10s

Я удалил папку /etc/luks-keys и использовал gnome-disks, чтобы воссоздать папку и файл ключа, поэтому права доступа 100% ОК, и этот файл также не должен содержать символ новой строки в конце. Если вы создаете его с помощью nano, вам нужно использовать дополнительный переключатель, чтобы он не добавлял новую строку. У меня есть опыт с этим. Очевидно, я использую одну и ту же фразу для всех своих накопителей.

А вот и странная часть, почему мне также не нужно показывать вам свой fstab:

Конфигурации действительно работают! Когда я загружаю Ubuntu и открываю gnome-disks, все, что мне нужно сделать, это нажать на значок замка под моими разделами luks, и они будут смонтированы мгновенно, не запрашивая пароль root или фразу для luks, так что на самом деле это работает, просто не при загрузке.

Что я уже пробовал, так это удалить nofail с двух дисков, которые на данный момент подключены к моему ПК. Это не помогает.

Я также пробовал sudo update-initramfs -u и sudo update-initramfs -c -k all, потому что они появились, когда я искал информацию. Я помню, что эти команды работали медленнее, они теперь практически мгновенные.

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

• Фреймворк “ask-password”, используемый для запроса паролей LUKS жестких дисков или паролей SSL во время загрузки, получил поддержку кэширования паролей в ключевом кольце ядра, если оно доступно. Это гарантирует, что пользователю нужно ввести фразу доступа всего один раз, если есть несколько объектов для разблокировки с одной и той же фразой. Ранее такое кэширование паролей было доступно только при использовании Plymouth; это переносит логику кэширования непосредственно в кодовую базу systemd.
  Утилита “systemd-ask-password” получила новый переключатель –keyname= для управления тем, какой ключ ключевого кольца ядра использовать для кэширования пароля. Эта функциональность также полезна для включения дисплейных менеджеров, таких как gdm, для автоматической разблокировки ключевого кольца GNOME пользователя, если его фраза доступа, пароль пользователя и пароль жесткого диска совпадают, если используется gdm-autologin.

Как я мог бы это использовать? Я пробовал поставить none вместо пути к файлу ключа, но это не сработало, хотя, возможно, я забыл обновить initramfs, если это необходимо.

Затем есть /etc/cryptsetup-initramfs/conf-hook

#
# Конфигурационный файл для хука cryptroot initramfs.
#

#
# KEYFILE_PATTERN: ...
#
# Значение этой переменной интерпретируется как шаблон для оболочки.
# Соответствующие файлы ключей из crypttab(5) включены в изображение initramfs.
# Связанные устройства могут затем быть разблокированы без ручного
# вмешательства. (Например, если в /etc/crypttab указаны два файла ключей
# /etc/keys/{root,swap}.key, вы можете установить KEYFILE_PATTERN="/etc/keys/*.key"
# для добавления их в initrd.)
#
# Если KEYFILE_PATTERN равно null или не задано (по умолчанию), то никакой файл ключа не
# будет скопирован в изображение initramfs.
#
# Обратите внимание, что glob(7) не расширяется для записей crypttab(5) с параметром
# 'keyscript=". В этом случае поле не обрабатывается как имя файла,
# а передается как аргумент для keyscript.
#
# ПРЕДУПРЕЖДЕНИЕ:
# * Если изображение initramfs должно включать конфиденциальные ключевые материалы, вам
#   следует создать его с ограничительным umask, чтобы не допустить доступа
#   непривилегированных пользователей. Например, установите UMASK=0077 в
#   /etc/initramfs-tools/initramfs.conf
# * Если вы используете cryptsetup-suspend, конфиденциальные ключевые материалы внутри
#   initramfs будут находиться в памяти в течение периода приостановки, что
#   делает бессмысленным использование cryptsetup-suspend.
#

#KEYFILE_PATTERN=

#
# ASKPASS: [ y | n ]
#
# Нужно ли включать двоичный файл askpass в изображение initramfs. askpass
# необходим для интерактивных запросов фразы доступа, и ASKPASS=y (по умолчанию)
# подразумевается, когда хук обнаруживает, что то же устройство нужно
# разблокировать в интерактивном режиме (т.е. не через файл ключа или keyscript)
# на стадии initramfs. Установка ASKPASS=n также пропускает включение `cryptroot-unlock`,
# так как это требует исполняемого файла askpass.

#ASKPASS=y

У меня есть стандартная настройка, где /boot не зашифрован, а мой корневой раздел по-прежнему является LV с только одним ext4 внутри него, по какой-то причине. Поэтому, когда меня просят ввести пароль, он разблокирует основной и единственный раздел Ubuntu и имеет доступ к /etc/luks-keys, так что не уверен, изменилось ли что-то здесь, но мне кажется, что нет необходимости копировать их в ramdisk, но возможно, это то, что мне нужно? Изменилось ли это? Менее безопасно держать их всегда в ОЗУ, но для меня это не проблема, так как я считаю, что моя система скомпрометирована, если кто-то получит физический доступ.

ASKPASS=y кажется по умолчанию, и меня, на самом деле, просят ввести пароль, просто, похоже, он не используется для других дисков, и файл ключа не считывается при загрузке. Снова всё это нормально работало в 22.04 без каких-либо других изменений, которые я помню.

Посмотрите на https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/2084251.

Установка systemd-cryptsetup решила мою проблему.

sudo apt-get install systemd-cryptsetup