Проблемы при вводе пароля LUKS

В общей цепочке загрузки (см ниже) initramfs работает до того как начинает работать любая система инициализации.

{BIOS/EFI/UEFI} -> загрузчик -> kernel -> initramfs -> {система инициализации/systemd/openrc/upstart}

«Гонка юнитов» начнется после того как отработает в initramfs отработает switch_root и сменит корень с initramfs-а на реальный root.

Так что разбирайся со своими тараканами.

Не уловил мысль. Окей, лишний тег. У меня не корень в контейнере же.

У меня не корень в контейнере же.

Тогда я «не уловил» при чем здесь тогда LUKS и initramfs?

Что у тебя зашифровано? Куда монтируется LUKS?

Написано в посте. var и home. С отдельных разделов.

Написано в посте. var и home. С отдельных разделов.

Ок. var и home у тебя в LUKS. И судя по «гонке юнитов» и перехвату фокуса ввода монтируешь ты их вовсе не при помощи initramfs а при помощи systemd.

Если-бы ты монтировал var и home в initramfs оно бы тебя тупо спросило бы пасворд а в systemd да там в параллель понесется всё а как дойдет до LUKS начнет ждать от тебя пароля вперемешку выплёвывая разное на екран.

Повторяю внимательно разбирайся со своими тараканами.

Какими тараканами, ёбт? Сказать-то что хотел?

Он имеет в виду то, что если те юниты монтируются systemd, предсказать, что с ними будет, уже нельзя. Хочешь предсказуемой работы декрипта — раскриптовывай еще в стадии initramfs.

Какими тараканами, ёбт?

Со своими тараканами «ёбт»!

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

Лол.

И да anonymous в этой фразе прав поскольку у systemd юниты в параллель и в тот момент пока один юнит ждет от тебя пароль другие будут срать своим выхлопом в ту же консоль. А в сумме ты будешь иметь то что и имеешь.

С любовью. Всегда твой Капитан.

LUKS-контейнер разблокируется в initramfs или после него? Если первое, то initramfs на скриптах или на systemd? Приведи fstab/crypttab/kernel cmdline/mkinitcpio.conf.

LUKS-контейнер разблокируется в initramfs или после него?

Под конец первой страницы выяснили что LUKS у него разблокирует не initramfs а systemd.

Ой, я тред не прочитал.А, всё равно в треде ничего полезного, один срач. Если что в арче в initramfs тоже может быть systemd.

После-после.

/dev/disk/by-partlabel/root	/		ext4	rw,relatime,data=ordered	0 1
/dev/disk/by-partlabel/EFI	/boot		vfat	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2
/dev/mapper/var			/var		ext4	rw,relatime,nodev,noexec	0 3
/dev/mapper/home		/home		ext4	rw,relatime,nodev		0 4
/dev/disk/by-partlabel/nogaems	/nogaems	ntfs	rw,user,uid=1000
/dev/disk/by-partlabel/ext	/ext		ext4	auto,nofail,rw,relatime,data=ordered 0 0

var		/dev/disk/by-partlabel/var
home		/dev/disk/by-partlabel/home

root=PARTLABEL=root rw

MODULES="i915"
HOOKS="base systemd sd-plymouth autodetect modconf block sd-encrypt filesystems keyboard fsck"

В initramfs, который генерирует dracut, в качестве init тоже может быть systemd, с юнитами и прочим.

Кстати, если кто объяснит практическую разницу между обычными хуками и systemd'шными буду очень благодарен.

Т. е. у тебя не LVM-on-LUKS, а отдельно закриптованы два GPT-раздела? Сейчас попробую воспроизвести.

Элементарно: внутри initramfs у тебя может быть как «классический» скрипт запуска, написанный полностью вручную, так и экземпляр systemd. Это зависит от того, включен ли у тебя хук systemd.

Дальше, хуки бывают двух видов: такие, которые просто добавляют в initramfs какие-то файлы (например, модули ядра), и такие, которые добавляют в initramfs новую логику, т. е. «дописывают» в главный скрипт запуска какие-то куски кода. Очевидно, хуки второго типа несовместимы с systemd, т. к. в этом случае в initramfs просто нет никакого «главного скрипта». Соответственно, то, что ты видишь — это их варианты, переделанные под systemd.

Спасибо. Это я более-менее понимаю. Вопрос скорее в том, какой мне как пользователю профит (или наоборот) от «новых» хуков?

Не, LVM вообще нет. Хочется доступ к музыке из под оффтопика иметь.

Пользователю от systemd (и всего, что с ним связано) профита нет никакого от слова совсем.

В initramfs, который генерирует dracut, в качестве init тоже может быть systemd, с юнитами и прочим.

И что? В «initramfs, который генерирует dracut» с systemd в роли init тоже 100500 юнитов которые перебивая друг-друга мешают ТС ввести его пароль для LUKS-а?

Ну фиг знает. Человеческое логирование — уже профит огого.

Как минимум там есть юниты для работы с блочными устройствами, в т.ч. LUKS, LVM, всякие триггеры udev и автогенерируемые юниты systemd, которые могут активироваться после появления того или иного устройства.

Я не говорю, что в этом 100% проблема, но и не откидывал бы такую возможность. Впрочем, изучить initramfs можно с помощью отладочного шелла, и посмотреть, что там наделал systemd.

Пользователь != чайник.

Ой лол. Plymouth был виноват. Отключал его, но почему-то увидел ложно отрицательный результат. Всем спасибо.

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

Забавно. А я так и не успел у себя настроить LUKS, чтобы воспроизвести.

А что, Plymouth не регистрируется в systemd'шном ask-password как агент?

Как минимум там есть юниты

Очевидно. Главный вопрос в их количестве.

Да фиг с ним, игрушка же. Никогда должным образом Plymouth в арче не работал и походу никогда не будет. Что в общем странно, потому что в убунте/федоре сплэш с первых секунд со всеми запросами практически на любом оборудовании. Наверное какие-то секретные патчи, лол.

У меня была похожая проблема на ноуте, когда установил Plymouth поверх драйверов радеон. Вот так у меня заработало нормально:

%cat /etc/mkinitcpio.conf
MODULES="radeon"
FILES="/etc/modprobe.d/uvesafb.conf"
HOOKS="base udev plymouth autodetect modconf block plymouth-encrypt lvm2 btrfs filesystems keyboard consolefont keymap fsck vboxhost"

% cat /etc/modprobe.d/uvesafb.conf
#
# This file sets the parameters for uvesafb module.
# The following format should be used:
# options uvesafb mode=<xres>x<yres>[-<bpp>][@<refresh>] scroll=<ywrap|ypan|redraw> ...
#
# For more details see:
# http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/fb/uvesafb.txt
#
 
options uvesafb mode_option=1366x768-32 scroll=ywrap

Никогда должным образом Plymouth в арче не работал и походу никогда не будет.

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

Попробую как совсем скучно будет, спасибо.