Bug 34854 - Не грузится 4.16.4-un-def
: Не грузится 4.16.4-un-def
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/kernel-image-un-def)
: unstable
: all Linux
: P3 major
Assigned To:
:
:
:
: 34865
: 34860
  Show dependency tree
 
Reported: 2018-04-26 12:02 by
Modified: 2018-08-10 14:32 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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