34854 2018-04-26 12:02:43 +0300 Не грузится 4.16.4-un-def 2018-08-10 14:32:38 +0300 1 1 4 Development Sisyphus kernel-image-un-def unstable all Linux CLOSED FIXED P3 major --- 34865 34860 1 vladimir.didenko vt aen antohami kernelbot klark.devel klark legion placeholder snejok vt qa-sisyphus oldest_to_newest 170648 0 vladimir.didenko 2018-04-26 12:02:43 +0300 Последнее ядро un-def 4.16.4 отказывается грузиться. Говорят, что модуля crc32c в initrd не хватает. 170653 1 mike 2018-04-26 13:30:31 +0300 Пришлось откатывать регулярки 20180425 до 20180418. 170655 2 boyarsh 2018-04-26 13:38:32 +0300 Хм...проблема где-то между ядром и make-initrd Вообще, мне кажется, похожая проблема когда-то (несколько лет назад) уже была, но с ходу найти не могу. 170656 3 snejok 2018-04-26 13:50:40 +0300 У нас был тонкий момент: Это ядро пытались запускать на 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. ... 170657 4 mike 2018-04-26 14:03:40 +0300 (В ответ на комментарий №2) > похожая проблема когда-то (несколько лет назад) уже была Именно, и мне кажется, что тоже с crc* (или даже crc32?). 170684 5 mike 2018-04-27 12:43:21 +0300 Говорят, что 4.16.5 приехало неисправленным -- его проверяли загрузкой? https://lists.altlinux.org/pipermail/sisyphus/2018-April/366675.html 170697 6 mike 2018-04-27 19:18:11 +0300 Объезд -- добавить в /etc/initrd.mk строчку MODULES_PRELOAD += crc32 А в предыдущий раз, насколько припомнил, вылезло боком какое-то хитрое изменение межмодульных зависимостей в ядре вида "была жёсткая, стала мягкая" (безусловная поменялась на условную, подробностей совершенно не помню). 170700 7 aen 2018-04-27 19:44:55 +0300 Не похоже на это: https://bugs.archlinux.org/task/49380 ? это 170701 8 repository-robot 2018-04-27 20:16:07 +0300 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) 170702 9 aen 2018-04-27 20:17:59 +0300 Исправление для p8, ошибка на Sisyphus. 170705 10 sbolshakov 2018-04-27 20:47:17 +0300 Пожалуйста, не нужно чинить это с помощью hard dependency в make-initrd поскольку crypto в ядре имеет сильную arch-зависимую составляющую достаточно было бы иметь (для x86): CONFIG_CRYPTO_CRC32C=y <= (а не =m) и CONFIG_CRYPTO_CRC32C_INTEL=m 170707 11 vt 2018-04-27 21:21:24 +0300 Загрузка 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 уже никто, скорее всего, не загрузит (надо бы проверить). 170708 12 klark.devel 2018-04-27 22:23:28 +0300 (В ответ на комментарий №10) > Пожалуйста, не нужно чинить это с помощью hard dependency Сказали срочно сделать именно так. Согласен полностью, что исправлению место не в make-initrd. Это временный костыль. Простите, с багом тоже погорячился. 170713 13 antohami 2018-04-28 06:32:32 +0300 Висит баг явно не на том компоненте у нас. Проблема касается не только ядра un-def, но и std-def. В Сизифе надо до вторника тоже исправить, хоть как-то, но исправить. Иначе регулярки следующей недели опять пойдут в утиль. Думаю, все в курсе, но на всякий случай написал. 170716 14 aen 2018-04-28 07:45:32 +0300 (В ответ на комментарий №13) > Висит баг явно не на том компоненте у нас. Проблема касается не только ядра > un-def, но и std-def. Ну так развесьте правильно. 170719 15 antohami 2018-04-28 07:57:00 +0300 (В ответ на комментарий №14) > (В ответ на комментарий №13) > > Висит баг явно не на том компоненте у нас. Проблема касается не только ядра > > un-def, но и std-def. > > Ну так развесьте правильно. Раз патч к make-initrd, то и баг перевешиваю на make-initrd. 170721 16 aen 2018-04-28 08:13:05 +0300 (В ответ на комментарий №15) > (В ответ на комментарий №14) > > (В ответ на комментарий №13) > > > Висит баг явно не на том компоненте у нас. Проблема касается не только ядра > > > un-def, но и std-def. > > > > Ну так развесьте правильно. > > Раз патч к make-initrd, то и баг перевешиваю на make-initrd. Не грузится ядро. Не стоит предсказывать решение, оно до конца не ясно. А вот если у Вас не грузится std-def, то повесьте на него тоже. Но проверьте. 170722 17 vt 2018-04-28 08:51:58 +0300 > Не грузится ядро. Не грузятся модули из initrd. Потому что их там нет. А initrd создается make-initrd. 170723 18 aen 2018-04-28 09:00:38 +0300 (В ответ на комментарий №17) > > Не грузится ядро. > > Не грузятся модули из initrd. Потому что их там нет. А initrd создается > make-initrd. Ок. Тогда нужно сформулировать и повесить новую багу на make-initrd, а эту в зависимости. 170724 19 vt 2018-04-28 09:01:44 +0300 Поясняю для начальства. В пакете ядра, 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. 170725 20 aen 2018-04-28 09:06:46 +0300 (В ответ на комментарий №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 с корректной формулировкой и заголовком? 170727 21 klark.devel 2018-04-28 11:23:36 +0300 (В ответ на комментарий №17) > > Не грузится ядро. > > Не грузятся модули из initrd. Потому что их там нет. А initrd создается > make-initrd. В make-initrd отродясь не было модулей. Ни одного. crc32c стал единственным. Но он действительно имеет некий интеллект при помещении модулей в initramfs, поскольку умеет по зависимостям определять другие требуемые модули. В нашем случае, как я понимаю, зависимость от crc32c стала более мягкой, и это изменение произошло где-то при сборке ядра. Я прибил его гвоздями к make-initrd в надежде, что Антон, как только сможет, решит более правильно там, где нужно. 170731 22 vt 2018-04-28 12:19:57 +0300 (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 её не увидел. 170735 23 klark.devel 2018-04-28 12:34:58 +0300 Видимо где-то очень близко подошли к сути! (В ответ на комментарий №22) > Я же написал откуда взялось требование crc32c в Comment #11. Эта "зависимость" > не через depends свойство модуля, вероятно поэтому make-initrd её не увидел. В нашем случае make-initrd делает примерно следующее: depmod -a -F "/boot/System.map-$KERNEL" "$KERNEL" 170743 24 vt 2018-04-28 13:16:59 +0300 Прошу кого-нибудь кто воспроизводил проблему ответить в Bug 34865. 170765 25 legion 2018-04-28 17:16:21 +0300 (В ответ на комментарий №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. 170934 26 boyarsh 2018-05-07 12:48:55 +0300 (В ответ на комментарий №4) > (В ответ на комментарий №2) > > похожая проблема когда-то (несколько лет назад) уже была > Именно, и мне кажется, что тоже с crc* (или даже crc32?). https://bugzilla.altlinux.org/show_bug.cgi?id=28641 То же самое, но в xfs 170935 27 boyarsh 2018-05-07 12:49:49 +0300 (В ответ на комментарий №5) > Говорят, что 4.16.5 приехало неисправленным -- его проверяли загрузкой? > > https://lists.altlinux.org/pipermail/sisyphus/2018-April/366675.html Все ядра у нас проверяются загрузкой на этапе сборки, но при этом не используется ext4... 173349 28 repository-robot 2018-08-10 14:32:38 +0300 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)