Последнее ядро un-def 4.16.4 отказывается грузиться. Говорят, что модуля crc32c в initrd не хватает.
Пришлось откатывать регулярки 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)
