Странности при разблокировке шифрованного тома при загрузке Debian с Systemd

более адекватно

Поменяй таймаут юнита раскриптовки.

Мне кажется, что это - не выход. Таймаут должен быть, конечно, но мне хотелось бы, чтобы система корректно выпадала в emergency (или грузилась дальше).

юнита раскриптовки

Это остальной emergency тебе не поломает.

Ну тут смотри как выходит - в emergency я выпаду, если один таймаут пропущу, второй пропущу и введу пароль на третий.

Иначе - не попадаю (в случае, если emergency вызван таймаутом).

пропущу
пропущу

Да научись ты уже верно вводить пароль. %)

Я его нормально ввожу, и если я его неправильно ввожу, то проблемы не возникает — я просто ввожу его ещё раз. А так, я не могу даже тыкнуть кнопку на компе и оставить его включаться, приходится разгребать косяки либо ребутом, либо ожиданием таймаутов. Хотелось бы вместо костылей использовать изящные подпорки с барельефами.

Все благородные доны используют ключи.

Я не умею в дебиан, к сожалению (и в cryptsetup тоже не умею). Они там используют штатный systemd-шный ask-password или какой-то свой самописный костыль?

● systemd-cryptsetup@home_decrypt.service - Cryptography Setup for home_decrypt
   Loaded: loaded (/etc/crypttab)
   Active: active (exited) since Пт 2015-10-23 08:47:30 MSK; 9h ago
     Docs: man:crypttab(5)
           man:systemd-cryptsetup-generator(8)
           man:systemd-cryptsetup@.service(8)
  Process: 401 ExecStart=/lib/systemd/systemd-cryptsetup attach home_decrypt /dev/local-vg/home none luks (code=exited, status=0/SUCCESS)
 Main PID: 401 (code=exited, status=0/SUCCESS)

Вот что я выцепил. Тут содержится ответ на то, что необходимо для решения задачи?

Тут ничего не содержится.

Видимо, пиши багрепорт в дебиан — сейчас проверил, в арче/апстриме всё работает.

Написал багрепорт, но в дебиане, как известно, _не торопятся_.

Сейчас установлю Ubu 15.10 в Виртуалку и протестирую.

Всё окей.

Видать, проблема в том, что Дебиан традиционно _не_торопится_.

Кажется, я решил проблему, дописав в /etc/crypttab

timeout=1min

Дописал-то дописал, но не совсем понял происходящего. Получается, что через 1 минуту cryptsetup скажет - не, пароль мне не дали. Юнит падает, systemd говорит - опасность, emergency mode.

Если же я ставлю timeout=2min, то повторяется ситуация из заголовка. Выходит, что есть некий таймаут, который лежит между 1min и 2min, и при превышении которого systemd начинает вести себя неадекватно.

Что бы это могло быть, и почему так происходит?

90 секунд; это может быть либо таймаут ожидания .device-юнита (JobTimeout= на dev-mapper-home_decrypt.device), либо таймаут запуска какого-либо другого юнита (TimeoutStartSec= на systemd-cryptsetup@home_decrypt.service). Скорее всего, первое, т. к. timeout= из crypttab должен по идее отображаться напрямую на второе.

В теперешнем апстриме у .device-юнита таймаут принудительно отключен, но я словил ещё одну багу: если указать в cryptsetup параметр nofail, то оно не будет ждать, пока ты введёшь пароль, а тупо продолжит грузиться дальше поверх строки запроса пароля. Видимо, куда-то After=-зависимость недовоткнута.

Сейчас, с timeout=1min, меня всё устраивает, вроде, но не покидает ощущение корявости решения. Что бы ты посоветовал сделать? Если .device-юниты генерируются динамически, то где необходимо изменить timeout, чтобы получить апстримное поведение? Правильно ли я понимаю, что один из тих таймаутов, которые ты описал, можно изменить с помощью x-systemd.device-timeout=, и если я установлю этот параметр равным нулю, то получу близкое к апстриму поведение?

Убери таймаут и сделай у себя вот это:

cd /tmp
mkdir dump/{fstab,cryptsetup}
/usr/lib/systemd/system-generators/systemd-fstab-generator dump/fstab{,,}
sudo /usr/lib/systemd/system-generators/systemd-fstab-generator dump/cryptsetup{,,}
tar -c dump | base64 | curl -F 'f:1=<-' ix.io

А что это?

Команды, блин.

Тестовый запуск двух генераторов юнитов (из fstab и crypttab), потом архив того, что нагенерилось, и аплоад этого архива (закодированного base64) на pastebin-подобный ix.io.

http://ix.io/lAB

Поправил в четвёртой строке fstab-генератор на cryptsetup

Ага.

В systemd твоей версии бага: неправильно задаётся отсутствие таймаута ожидания зашифрованного устройства. Вместо файла dev-mapper-home_decrypt.device.d/90-device-timeout.conf создаётся файл home_decrypt.device.d/90-device-timeout.conf.

Ну а юнита с таким именем не существует, потому что имя device-юнитов соответствует полному пути до файла устройства.

Сделать можно примерно следующее:

sudo cp -vrT /run/systemd/generator/home_decrypt.device.d /etc/systemd/system/dev-mapper-home_decrypt.device.d

А ещё стоит зарепортить это в дебиан, указав им на коммит a6fb0dc138d4e7895f8e607493279dbe4df117a1 и багрепорт #84409 (ещё в старой багзилле).

Большое спасибо. Я напишу багрепорт и сделаю так, как ты советуешь.

Хм, баг оформлять не буду.

Всё равно в Stable не починят, а в Testing уже 227.

Почему не починят? Там всего-то однострочный патч наложить нужно. Если это не починят — то в дебиане реально какие-то тормоза сидят.

Лично моё мнение, как человека сидящего на стейбл ветке. У нас быстро только security фиксы прилетают. Если бага висит в апстриме стабильной ветки - она там провисит оооочень долго. Но как правило подобные баги не критичны из-за особенностей подготовки релиза (неоднократное тестирование, замарозка, закрывание всех багов, етс).

Зарепортил.

Починили, сейчас обсуждают, можно ли это продвинуть в stable.

Нет, не починили, а торжественно объявили версию, в которой это уже починено апстримом :)

Дебиан такой дебиан. Там, блин, однострочный тривиальный патч на исходник генератора, причём явно без побочных эффектов, чего там обсуждать-то?..

Для начала, следует убедиться в том, что он однострочный. Затем - в том, что он тривиальный. Потом - что он является патчем, причём именно на то, на что нужно. И, наконец, надо убедиться, что он явно без побочных эффектов.

Да, эти ребята не торопятся, но мне Debian чем-то близок.