Пришлось откатывать регулярки 20180425 до 20180418.

Хм...проблема где-то между ядром и make-initrd

Вообще, мне кажется, похожая проблема когда-то (несколько лет назад) уже была, но с ходу найти не могу.

У нас был тонкий момент:
Это ядро пытались запускать на spt7, поэтому сначала не придали большого значения.

Оставлю для гугла:

initrd отваливается со словами:
...
mount: mount(2) failed: No such file or directory
mount: mount(2) failed: No such file or directory
mount: mount(2) failed: No such file or directory
...

В dmesg:
...
EXT4-fs (sda2): Cannot load crc32c driver.
EXT4-fs (sda2): Cannot load crc32c driver.
EXT4-fs (sda2): Cannot load crc32c driver.
...

(В ответ на комментарий №2)
> похожая проблема когда-то (несколько лет назад) уже была
Именно, и мне кажется, что тоже с crc* (или даже crc32?).

Говорят, что 4.16.5 приехало неисправленным -- его проверяли загрузкой?

https://lists.altlinux.org/pipermail/sisyphus/2018-April/366675.html

Объезд -- добавить в /etc/initrd.mk строчку MODULES_PRELOAD += crc32

А в предыдущий раз, насколько припомнил, вылезло боком какое-то хитрое изменение межмодульных зависимостей в ядре вида "была жёсткая, стала мягкая" (безусловная поменялась на условную, подробностей совершенно не помню).

Не похоже на это: https://bugs.archlinux.org/task/49380 ? это

make-initrd-0.8.15-alt1.M80P.6 -> p8:

Fri Apr 27 2018 Leonid Krivoshein <klark@altlinux> 0.8.15-alt1.M80P.6
- Hard dependency to crc32c module added (Closes: #34854)

Исправление для p8, ошибка на Sisyphus.

Пожалуйста, не нужно чинить это с помощью hard dependency в make-initrd
поскольку crypto в ядре имеет сильную arch-зависимую составляющую
достаточно было бы иметь (для x86): 
CONFIG_CRYPTO_CRC32C=y <= (а не =m) и
CONFIG_CRYPTO_CRC32C_INTEL=m

Загрузка crc32c в fs/ext4/super.c появилась с версии v4.16-rc1-18-ga45403b51582 для фикса CVE-2018-1094.

Поэтому, на старых ядрах такой ошибки не могло быть.

"Hard dependency" мне представляется шагом в правильном направлении, если есть ext fs, то должно быть и crc32c.

> CONFIG_CRYPTO_CRC32C=y <= (а не =m) и
> CONFIG_CRYPTO_CRC32C_INTEL=m

Если в initrd нет нужного модуля, то, предполагаю, что это все равно что `CONFIG_CRYPTO_CRC32C_INTEL=n`, так как 'позже' crc32c-intel уже никто, скорее всего, не загрузит (надо бы проверить).

(В ответ на комментарий №10)
> Пожалуйста, не нужно чинить это с помощью hard dependency

Сказали срочно сделать именно так. Согласен полностью, что исправлению место не в make-initrd. Это временный костыль. Простите, с багом тоже погорячился.

Висит баг явно не на том компоненте у нас. Проблема касается не только ядра un-def, но и std-def.
В Сизифе надо до вторника тоже исправить, хоть как-то, но исправить. Иначе регулярки следующей недели опять пойдут в утиль.
Думаю, все в курсе, но на всякий случай написал.

(В ответ на комментарий №13)
> Висит баг явно не на том компоненте у нас. Проблема касается не только ядра
> un-def, но и std-def.

Ну так развесьте правильно.

(В ответ на комментарий №14)
> (В ответ на комментарий №13)
> > Висит баг явно не на том компоненте у нас. Проблема касается не только ядра
> > un-def, но и std-def.
> 
> Ну так развесьте правильно.

Раз патч к make-initrd, то и баг перевешиваю на make-initrd.

(В ответ на комментарий №15)
> (В ответ на комментарий №14)
> > (В ответ на комментарий №13)
> > > Висит баг явно не на том компоненте у нас. Проблема касается не только ядра
> > > un-def, но и std-def.
> > 
> > Ну так развесьте правильно.
> 
> Раз патч к make-initrd, то и баг перевешиваю на make-initrd.

Не грузится ядро. Не стоит предсказывать решение, оно до конца не ясно.
А вот если у Вас не грузится std-def, то повесьте на него тоже. Но проверьте.

> Не грузится ядро.

Не грузятся модули из initrd. Потому что их там нет. А initrd создается make-initrd.

(В ответ на комментарий №17)
> > Не грузится ядро.
> 
> Не грузятся модули из initrd. Потому что их там нет. А initrd создается
> make-initrd.
Ок. Тогда нужно сформулировать и повесить новую багу на make-initrd, а эту в зависимости.

Поясняю для начальства.

В пакете ядра, kernel-image-un-def-4.16.5-alt1.x86_64.rpm, нужные модули есть.

$ less kernel-image-un-def-4.16.5-alt1.x86_64.rpm | grep /crc32c
-rw-------    1 root    root                     6125 апр 26 16:18 /lib/modules/4.16.5-un-def-alt1/kernel/arch/x86/crypto/crc32c-intel.ko.gz
-rw-------    1 root    root                     1721 апр 26 16:18 /lib/modules/4.16.5-un-def-alt1/kernel/crypto/crc32c_generic.ko.gz

Следовательно, ядро собрано правильно. Но эти модули не попадают на "диск" initrd.

Есть два решения 1) исправить make-initrd, 2) включить эти модули внутрь ядра, раз прога глючит.

Обоснование второго варианта решения мне кажется не правильным так как подрывает сам фунционал initrd.

(В ответ на комментарий №19)
> Поясняю для начальства.
Спасибо. Но это начальству уже понятно.
> 
> В пакете ядра, kernel-image-un-def-4.16.5-alt1.x86_64.rpm, нужные модули есть.
> 
> $ less kernel-image-un-def-4.16.5-alt1.x86_64.rpm | grep /crc32c
> -rw-------    1 root    root                     6125 апр 26 16:18
> /lib/modules/4.16.5-un-def-alt1/kernel/arch/x86/crypto/crc32c-intel.ko.gz
> -rw-------    1 root    root                     1721 апр 26 16:18
> /lib/modules/4.16.5-un-def-alt1/kernel/crypto/crc32c_generic.ko.gz
> 
> Следовательно, ядро собрано правильно. Но эти модули не попадают на "диск"
> initrd.
> 
> Есть два решения 1) исправить make-initrd, 2) включить эти модули внутрь ядра,
> раз прога глючит.
> 
> Обоснование второго варианта решения мне кажется не правильным так как
> подрывает сам фунционал initrd.
Так что мешает повесить багу на make-initrd с корректной формулировкой и заголовком?

(В ответ на комментарий №17)
> > Не грузится ядро.
> 
> Не грузятся модули из initrd. Потому что их там нет. А initrd создается
> make-initrd.

В make-initrd отродясь не было модулей. Ни одного. crc32c стал единственным. Но он действительно имеет некий интеллект при помещении модулей в initramfs, поскольку умеет по зависимостям определять другие требуемые модули. В нашем случае, как я понимаю, зависимость от crc32c стала более мягкой, и это изменение произошло где-то при сборке ядра. Я прибил его гвоздями к make-initrd в надежде, что Антон, как только сможет, решит более правильно там, где нужно.

(In reply to comment #21)
> (В ответ на комментарий №17)
> > > Не грузится ядро.
> > 
> > Не грузятся модули из initrd. Потому что их там нет. А initrd создается
> > make-initrd.
> 
> В make-initrd отродясь не было модулей. Ни одного.

Я писал, что модули в make-initrd?

> crc32c стал единственным.

Регулярка, которую ты ставил в феврале:

/boot# initrd-ls initrd-4.14.15-un-def-alt1.img|grep -c ko
33

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

Которых отродясь не было?

> В нашем
> случае, как я понимаю, зависимость от crc32c стала более мягкой, и это
> изменение произошло где-то при сборке ядра.

Что за мягкое-твёрдое?

Я же написал откуда взялось требование crc32c в Comment #11. Эта "зависимость" не через depends свойство модуля, вероятно поэтому make-initrd её не увидел.

Видимо где-то очень близко подошли к сути!

(В ответ на комментарий №22)
> Я же написал откуда взялось требование crc32c в Comment #11. Эта "зависимость"
> не через depends свойство модуля, вероятно поэтому make-initrd её не увидел.

В нашем случае make-initrd делает примерно следующее:

depmod -a -F "/boot/System.map-$KERNEL" "$KERNEL"

Прошу кого-нибудь кто воспроизводил проблему ответить в Bug 34865.

(В ответ на комментарий №22)
> > В нашем
> > случае, как я понимаю, зависимость от crc32c стала более мягкой, и это
> > изменение произошло где-то при сборке ядра.
> 
> Что за мягкое-твёрдое?

В ядре есть явные зависимости и не явные (softdep).

> Я же написал откуда взялось требование crc32c в Comment #11. Эта "зависимость"
> не через depends свойство модуля, вероятно поэтому make-initrd её не увидел.

Это очень странно. Похожая зависимость, например, у xfs:

# modinfo xfs |grep depends
depends:        libcrc32c

он явно требует libcrc32c, что на само деле тоже вызывает проблемы т.к. libcrc32c неявно хочет архитектурную реализацию crc32c. Сейчас её можно проследить через softdeps.

Но тут всё интереснее:

# modinfo ext4 |grep depends
depends:        mbcache,fscrypto,jbd2,crc16

Оно явно хочет crc16, но не libcrc32c.

(В ответ на комментарий №4)
> (В ответ на комментарий №2)
> > похожая проблема когда-то (несколько лет назад) уже была
> Именно, и мне кажется, что тоже с crc* (или даже crc32?).

https://bugzilla.altlinux.org/show_bug.cgi?id=28641
То же самое, но в xfs

(В ответ на комментарий №5)
> Говорят, что 4.16.5 приехало неисправленным -- его проверяли загрузкой?
> 
> https://lists.altlinux.org/pipermail/sisyphus/2018-April/366675.html

Все ядра у нас проверяются загрузкой на этапе сборки, но при этом не используется ext4...

make-initrd-0.8.15-alt1.M80P.7 -> c8.1:

Mon Apr 30 2018 Leonid Krivoshein <klark@altlinux> 0.8.15-alt1.M80P.7
- Depinfo utility v2.0.9 ported from Sisyphus to p8 branch
- Hidden dependency for ext4 filesystem added

Fri Apr 27 2018 Leonid Krivoshein <klark@altlinux> 0.8.15-alt1.M80P.6
- Hard dependency to crc32c module added (Closes: #34854)

Wed Mar 14 2018 Lenar Shakirov <snejok@altlinux.ru> 0.8.15-alt1.M80P.5
- /etc/mtab moved from /proc/mounts symlink to regular empty file (Closes: #31465)

Tue Feb 27 2018 Lenar Shakirov <snejok@altlinux.ru> 0.8.15-alt1.M80P.3
- stage ucode after compress (closes: #34456)

Mon Dec 04 2017 Sergey V Turchin <zerg@altlinux> 0.8.15-alt1.M80P.2
- fix requires

Thu Nov 02 2017 Sergey V Turchin <zerg@altlinux> 0.8.15-alt1.M80P.1
- Backport ucode feature for early loading microcode.

Fri Oct 13 2017 Anton V. Boyarshinov <boyarsh@altlinux> 0.8.14-alt1.M80P.1
- ignore load_modules return (there are some warnings, poisioning 
  return code of modprobe) (Closes: #32749)

Tue Mar 21 2017 Sergey Novikov <sotor@altlinux> 0.8.14-alt1
- fixed lvm discovery return code in case, when non-root LVM volumes
  inaccessible from initramfs (closes: #33243)