Очевидно, что стартовые скрипты ожидать пока будет подключено устройство с ключом шифрования.

но флешка то подключена изначально, на ней находится grub и /boot
данное сообщение появляется уже после того как был дешифрован корневой раздел

вот скрин с vmware, пока на виртуалке разбираюсь в проблеме, если найдется решение перенесу на основную систему http://s015.radikal.ru/i331/1506/61/037c7acfbdc4.png

Модули поддержки USB в initramfs присутствуют?

тут дело не в usb, я когда начал разбираться с проблемой на виртуалке, попробовал сделать вместо флешки второй жесткий диск на пару гиг, и закинул на него /boot, grub и ключ, проблема осталась. Что на основной системе с флешкой, что на виртуальной с флешкой или дополнительным hdd, проблема одинакова, все грузится и работает, но задержка не уходит

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862

Один из многоуважаемых авторов systemd решил что половина случаев использования crypttab не нужна и выпилил опцию scriptdev.

Можно просто заставить systemd забыть про существование этого юнита, т.к. монтирование один хрен происходит из шелл-скрипта в initrd

Увы

/usr/share/doc/cryptsetup/README.initramfs.gz:

10. The «passdev» keyscript

If you have a keyfile on a removable device (e.g. a USB-key), you can use the passdev keyscript. It will wait for the device to appear, mount it read-only, read the key and then unmount the device.

The «key» part of /etc/crypttab will be interpreted as <device>:<path>[:<timeout>], it is strongly recommended that you use one of the persistent device names from /dev/disk/*, e.g. /dev/disk/by-label/myusbkey.

This is an example of a suitable line in cryptsetup: cryptroot /dev/hda2 /dev/disk/by-label/myusbkey:/keys/root.key cipher=aes-cbc-essiv:sha256,size=256,hash=plain,keyscript=/lib/cryptsetup/scripts/passdev

The above line would cause the boot to pause until /dev/disk/by-label/myusbkey appears in the fs, then mount that device and use the file /keys/root.key on the device as the key (without any hashing) as the key for the fs.

The timeout option has to be in seconds.

If any modules are required in order to mount the filesystem on the removable device, then initramfs-tools needs to be configured to add these modules to the initramfs. This can be done by listing the required modules in /etc/initramfs-tools/modules.

Указание ключевого файла в виде /dev/устройство:/путь/к/файлу требует keyscript=passdev, но release notes:

There are some cryptsetup features that are unfortunately not supported when running with systemd as the init system. These are:

<...>

• keyscript

If your system relies on any of these for successful booting, you will have to use sysvinit (sysvinit-core) as init system. Please refer to Section 5.6, “Upgrading installs the new default init system for Jessie” for how to avoid a particular init system.

Добавляйте флешку в fstab и указывайте путь к ключевому файлу от точки её монтирования.

Спасибо за ссылку. Сейчас на работе, вечером почитаю, посмотрим что получится

второе сообщение увидел уже позже, да я тоже заметил что при update-initramfs, требует keyscript. ну хотя-бы примерно понятно где копать, вечером гляну

M_Corvinus

кстати, можно фанатов системд позвать intelfx, узнать как они отмажутся по этому поводу

я в свое время сделал примерно так

systemctl mask systemd-cryptsetup@sda1_crypt.service

Чего тебе надобно?

У тебя там 4.2 выше. «Не впиливал» != «выпилил».

проверил указание пути через точку монтирования
если убрать keyscript, все равно ругается

cryptsetup: WARNING: target sda1_crypt uses a key file, skipped

буду копать дальше

systemctl mask systemd-cryptsetup@sda1_crypt.service

проблему решил, но как это повлияет на работу шифрования? можно поподробнее про блокировку systemd-cryptsetup@.service?

до тех пор пока в initrd существует скрипт, который умеет корректно читать crypttab - все будет работать, как только этот скрипт выпилят - нужно будет придумывать что-то новое, можно например написать свой systemd-cryptsetup@.service, который будет вызывать cryptdisks_{start,stop}

спасибо за помощь, надо будет поглубже разобраться с тем как все работает на данный момент, чтобы заранее подготовится к будущим приколам

Ну какбы уже давно существует описание формата crypttab(5), в котором описана работа keyscript
Ребята из systemd решили, что этот crypttab - неправильный и написали свой, без keyscript, precheck, check, с переименованием некоторых других опций и добавлением systemd-специфичных опций.

Написать свой, альтернативный crypttab - это и есть выпилить из оригинального ненужные опции.

давно существует описание формата crypttab(5), в котором описана работа keyscript

http://linux.die.net/man/5/crypttab — не вижу. «Ребята из systemd» не обязаны имплементить дебианоспецифичные расширения. Это задача мейнтейнеров systemd в Debian.

учитывая, что «The /etc/crypttab file format is based on the Debian cryptsetup package» - «дебианоспецифичные расширения» - это и есть нормальный формат cryptesetup, а все остальное - дистрибутивоспецифичные расширения.

Нет, конечно. «Based on» — это именно «based on». От того, что в одном дистрибутиве что-то сделали, остальные дистрибутивы/проекты не становятся внезапно обязанными делать то же самое.

вообще если уж на то пошло, то мейнтейнеры systemd в Debian предлагали апстриму изменения, которые исправили бы этот недостаток, но аргументация апстрима в лице ЛП была удивительно хороша - вы не используете dbus, поэтому патчи я принимать не буду.

мейнтейнеры systemd в Debian предлагали апстриму изменения

вы не используете dbus, поэтому патчи я принимать не буду.

Где?

в списке рассылки, где же ещё

Не нашёл.

Леннарт предлагает вместо того, чтобы добавлять в systemd'шную инфраструктуру ask-password поддержку нетекстовых парольных фраз, воспользоваться сразу kernel keyring. И, чтобы два раза не ходить, взаимодействие между агентами было предложено перепилить с сокетов и inotify на kdbus.

И как бы он имеет полное право просить, чтобы в апстрим входили только «идейно» правильные решения. Почему мейнтейнеры не согласились применить патч (который вроде как даже был написан) локально — спрашивать нужно у них.

взаимодействие между агентами было предложено перепилить с сокетов и inotify на kdbus.

Вот же они, положила.

Почему мейнтейнеры не согласились применить патч локально

Если мне не изменяет память одним из достоинств убийцы sysvinit провозглашалась унификация между дистрибутивами. Если пойти по тому пути что ты предлагаешь через 5 лет у каждого дистрибутива будет свой несовместимый с остальными systemd, а через 10 администратор RHEL должен будет день разбираться чтобы понять как настроить включение сервиса в Gentoo.