Arch ck-kernel

break в kernel cmdline, источник.

mkinitcpio.conf:

MODULES=(intel_agp i915 nvme)
FILES=("/key.bin" "/etc/modprobe.d/modprobe.conf") 
HOOKS=(base udev autodetect modconf block keymap encrypt lvm2 filesystems keyboard fsck btrfs)

GRUB_CMDLINE_LINUX_DEFAULT="quiet kvm-intel.nested=1"
GRUB_CMDLINE_LINUX="cryptdevice=/dev/nvme0n1p3:cryptroot:allow-discards break=premount" 
GRUB_ENABLE_CRYPTODISK=y

mkinitcpio -p linux-ck

mkinitcpio -p linux пересобирает только initramfs пакета linux.

Подробности в /etc/mkinitcpio.d/

Попробовал и ck ядро и дефолтное, во всех случаях не загружается:

 running early hook [udev] 
running early hook [lvm]

systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M 

Как еще можно узнать, что случилось?

Запустить интерактивный shell внутри initramfs в начале загрузки и посмотреть на то какие блочные устройства доступны на этом этапе.

Коротко говоря понять почему break параметр не подействовал и исправить это.

init=/bin/bash так же безрезультатно. Убрал ключ из файлов. Система при загрузке не доходит то этого этапа, зависает еще до открытия диска.

Что именно имеется ввиду под «безрезультатно»?

Параметр break=premount читается из cmdline ядра инитом в initramfs и при его наличии инит останавливает загрузку и запускает интерактивный шелл до монтирования файловых систем. Чтобы пользователь мог оценить ситуацию изнутри initramfs и возможно вручную починить загрузку.

Параметр init= читается самим ядром, он не может не работать. Только если ты специально не патчил своё ядро игнорить его. Если ядро не было запатчено и init= «не работает» то может быть ядро и не получает его? Передаёт ли загрузчик этот параметр?

Безрезультатно это ничего не меняется. Скрин параметров загрузки - https://ibb.co/n3MZN9 И что бы я не делал, больше не отображается - https://ibb.co/hPHfvU и загрузка не идет.

И только с помощью одного systemd.log_level=debug удалось получить https://ibb.co/c9DCaU. Из-за этого не идет загрузка?

Не похоже, видно только вывод от udev хука, а висит lvm хук. Что может быть потому что pvscan ждёт готовность всех блочных устройств.

С какой целью добавлен btrfs хук? Судя по описанию он нужен только если нужно собирать мультидевайсные бтрфс при старте. Учитывая, что бтрфс похоже лежит на LVM on LUKS то это подразумевает, что бтрфс может быть на двух разных LVM томах в разных PV. А initramfs на base хуке не может разблокировать более одного LUKS тома во время загрузки, для этого нужно переключаться на systemd хук базу как описано в арчвики на Mkinitcpio.

С другой стороны тогда бы оно не работало и с обычным пакетом linux.

Скриншот логов хука udev не сходится с набором хуков из ранних постов: base udev autodetect modconf block keymap encrypt lvm2 filesystems keyboard fsck btrfs

на скриншоте видно срабатывание хука udev и сразу после него lvm2, когда согласно предоставленной строке хуков должен пройти как минимум block, keymap и encrypt и только потом lvm2. Тогда логично что оно не работает, т.к. LVM лежит на LUKS, который не разблокирован и pvscan его не видит.

Хуки в инитрамфс выстраиваются в том порядке в каком они указаны в /etc/mkinicpio.conf

Как пример мой массив хуков с лаптопа, который грузится с бтрфс на LVM on LUKS, но бтрфс строго на одном диске: base udev autodetect modconf block keymap encrypt lvm2 filesystems keyboard fsck btrfs

Косяк с моим массивом хуков, а срок редактирования истёк.
Вот корректная строка:
HOOKS=(base udev autodetect modconf block encrypt lvm2 filesystems keyboard fsck):

Если же бтрфс на более чем одном диске то тогда придется использовать примерно такой массив: HOOKS=(base systemd autodetect modconf block sd-encrypt sd-lvm2 fsck filesystems keyboard fsck)

Хук btrfs добавлен за-за того что вся ось лежит на btrfs - 3 subvolume - /,boot и /home. Набор хуков в mkinitcpio.conf не менялся - base udev autodetect modconf block keymap encrypt lvm2 filesystems keyboard fsck btrfs т.к. там важна последовательность и до обновления все идеально работало. Почему при загрузке меняется последовательность я к сожалению не знаю.

хук btrfs нужен только если фс находится на более чем одном блочном устройстве. Если btrfs находится на одном блочном устройстве то этот хук не нужен. Независимо от того корень это или нет.

Нужно убедиться, что initramfs генерится именно с тем mkinitcpio.conf, с которым ты думаешь. Как минимум оценить вывод mkinitcpio -p linux-ck или какое там имя у пресета. Судя по конфигу grub там может быть и mkinitcpio -p linux-ck-skylake, я отсюда не вижу.

Убрал хук btrfs, устройство у меня одно. Скрин генерации initramfs - https://ibb.co/j4Rkep, без ошибок и берется именно мой конфиг.

Попереставлял хуки, попробовал другое ядро, переустановил grub+mkinitcpio - ошибка осталась. При чем что бы я не делал она остается неизменной. Есть возможность скинуть fstab для сравнения? Может в нем проблема.

вот на том скрине (при выполнении hook udev) «ругается» на неизвестный тип файловой системы при монтировании /sys/fs/cgroup, и далее

Failed to determine root cgroup, ignoring cgroup memory limit: No medium found.

Разве это не ошибка и не влияет на следующие этапы старта системы?

Вот только с ней ничего не сделаешь. mkinitcpio без ошибок собирает с включением btrfs, хук данной фс ты можешь хоть перед udev поставить - все равно будет эта ошибка. Видимо не зря RedHat отказался от нее.

я писал про cgroup. для неё задан неизвестный тип файловой системы. отключить её монтирование при загрузке не вариант? а с failback image тоже ошибка не загружается?

может свой hook для монтирования cgroup создать?

failback image не загружается, такая же ошибка. Где можно поправить монтирование cgroup?

«лично» с такой ошибкой не сталкивался. предполагаю, что надо искать: посмотреть hook udev (скрипт же), mtab (fstab), юниты *.mount, в /etc...

как вариант, загрузится в /bin/bash и смотреть что, там реально намонтировано.