Bug 34854

Summary: Не грузится 4.16.4-un-def
Product: Sisyphus Reporter: Владимир Диденко <vladimir.didenko>
Component: kernel-image-un-defAssignee: Vitaly Chikunov <vt>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: major    
Priority: P3 CC: aen, antohami, kernelbot, klark.devel, klark, legion, placeholder, snejok, vt
Version: unstable   
Hardware: all   
OS: Linux   
Bug Depends on: 34865    
Bug Blocks: 34860    

Description Владимир Диденко 2018-04-26 12:02:43 MSK
Последнее ядро un-def 4.16.4 отказывается грузиться. Говорят, что модуля crc32c в initrd не хватает.
Comment 1 Michael Shigorin 2018-04-26 13:30:31 MSK
Пришлось откатывать регулярки 20180425 до 20180418.
Comment 2 Anton V. Boyarshinov 2018-04-26 13:38:32 MSK
Хм...проблема где-то между ядром и make-initrd

Вообще, мне кажется, похожая проблема когда-то (несколько лет назад) уже была, но с ходу найти не могу.
Comment 3 Lenar Shakirov 2018-04-26 13:50:40 MSK
У нас был тонкий момент:
Это ядро пытались запускать на 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.
...
Comment 4 Michael Shigorin 2018-04-26 14:03:40 MSK
(В ответ на комментарий №2)
> похожая проблема когда-то (несколько лет назад) уже была
Именно, и мне кажется, что тоже с crc* (или даже crc32?).
Comment 5 Michael Shigorin 2018-04-27 12:43:21 MSK
Говорят, что 4.16.5 приехало неисправленным -- его проверяли загрузкой?

https://lists.altlinux.org/pipermail/sisyphus/2018-April/366675.html
Comment 6 Michael Shigorin 2018-04-27 19:18:11 MSK
Объезд -- добавить в /etc/initrd.mk строчку MODULES_PRELOAD += crc32

А в предыдущий раз, насколько припомнил, вылезло боком какое-то хитрое изменение межмодульных зависимостей в ядре вида "была жёсткая, стала мягкая" (безусловная поменялась на условную, подробностей совершенно не помню).
Comment 7 AEN 2018-04-27 19:44:55 MSK
Не похоже на это: https://bugs.archlinux.org/task/49380 ? это
Comment 8 Repository Robot 2018-04-27 20:16:07 MSK
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)
Comment 9 AEN 2018-04-27 20:17:59 MSK
Исправление для p8, ошибка на Sisyphus.
Comment 10 Sergey Bolshakov 2018-04-27 20:47:17 MSK
Пожалуйста, не нужно чинить это с помощью hard dependency в make-initrd
поскольку crypto в ядре имеет сильную arch-зависимую составляющую
достаточно было бы иметь (для x86): 
CONFIG_CRYPTO_CRC32C=y <= (а не =m) и
CONFIG_CRYPTO_CRC32C_INTEL=m
Comment 11 Vitaly Chikunov 2018-04-27 21:21:24 MSK
Загрузка 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 уже никто, скорее всего, не загрузит (надо бы проверить).
Comment 12 Leonid Krivoshein 2018-04-27 22:23:28 MSK
(В ответ на комментарий №10)
> Пожалуйста, не нужно чинить это с помощью hard dependency

Сказали срочно сделать именно так. Согласен полностью, что исправлению место не в make-initrd. Это временный костыль. Простите, с багом тоже погорячился.
Comment 13 Антон Мидюков 2018-04-28 06:32:32 MSK
Висит баг явно не на том компоненте у нас. Проблема касается не только ядра un-def, но и std-def.
В Сизифе надо до вторника тоже исправить, хоть как-то, но исправить. Иначе регулярки следующей недели опять пойдут в утиль.
Думаю, все в курсе, но на всякий случай написал.
Comment 14 AEN 2018-04-28 07:45:32 MSK
(В ответ на комментарий №13)
> Висит баг явно не на том компоненте у нас. Проблема касается не только ядра
> un-def, но и std-def.

Ну так развесьте правильно.
Comment 15 Антон Мидюков 2018-04-28 07:57:00 MSK
(В ответ на комментарий №14)
> (В ответ на комментарий №13)
> > Висит баг явно не на том компоненте у нас. Проблема касается не только ядра
> > un-def, но и std-def.
> 
> Ну так развесьте правильно.

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

Не грузится ядро. Не стоит предсказывать решение, оно до конца не ясно.
А вот если у Вас не грузится std-def, то повесьте на него тоже. Но проверьте.
Comment 17 Vitaly Chikunov 2018-04-28 08:51:58 MSK
> Не грузится ядро.

Не грузятся модули из initrd. Потому что их там нет. А initrd создается make-initrd.
Comment 18 AEN 2018-04-28 09:00:38 MSK
(В ответ на комментарий №17)
> > Не грузится ядро.
> 
> Не грузятся модули из initrd. Потому что их там нет. А initrd создается
> make-initrd.
Ок. Тогда нужно сформулировать и повесить новую багу на make-initrd, а эту в зависимости.
Comment 19 Vitaly Chikunov 2018-04-28 09:01:44 MSK
Поясняю для начальства.

В пакете ядра, 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.
Comment 20 AEN 2018-04-28 09:06:46 MSK
(В ответ на комментарий №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 с корректной формулировкой и заголовком?
Comment 21 Leonid Krivoshein 2018-04-28 11:23:36 MSK
(В ответ на комментарий №17)
> > Не грузится ядро.
> 
> Не грузятся модули из initrd. Потому что их там нет. А initrd создается
> make-initrd.

В make-initrd отродясь не было модулей. Ни одного. crc32c стал единственным. Но он действительно имеет некий интеллект при помещении модулей в initramfs, поскольку умеет по зависимостям определять другие требуемые модули. В нашем случае, как я понимаю, зависимость от crc32c стала более мягкой, и это изменение произошло где-то при сборке ядра. Я прибил его гвоздями к make-initrd в надежде, что Антон, как только сможет, решит более правильно там, где нужно.
Comment 22 Vitaly Chikunov 2018-04-28 12:19:57 MSK
(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 её не увидел.
Comment 23 Leonid Krivoshein 2018-04-28 12:34:58 MSK
Видимо где-то очень близко подошли к сути!

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

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

depmod -a -F "/boot/System.map-$KERNEL" "$KERNEL"
Comment 24 Vitaly Chikunov 2018-04-28 13:16:59 MSK
Прошу кого-нибудь кто воспроизводил проблему ответить в Bug 34865.
Comment 25 Alexey Gladkov 2018-04-28 17:16:21 MSK
(В ответ на комментарий №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.
Comment 26 Anton V. Boyarshinov 2018-05-07 12:48:55 MSK
(В ответ на комментарий №4)
> (В ответ на комментарий №2)
> > похожая проблема когда-то (несколько лет назад) уже была
> Именно, и мне кажется, что тоже с crc* (или даже crc32?).

https://bugzilla.altlinux.org/show_bug.cgi?id=28641
То же самое, но в xfs
Comment 27 Anton V. Boyarshinov 2018-05-07 12:49:49 MSK
(В ответ на комментарий №5)
> Говорят, что 4.16.5 приехало неисправленным -- его проверяли загрузкой?
> 
> https://lists.altlinux.org/pipermail/sisyphus/2018-April/366675.html

Все ядра у нас проверяются загрузкой на этапе сборки, но при этом не используется ext4...
Comment 28 Repository Robot 2018-08-10 14:32:38 MSK
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)