Не грузится новое ядро

После недавнего обновления пакета calculate-sources обнаружился странный эффект. После запуска загрузчика GRUB предлагает выбрать ядро и параметры и если выбрать новое ядро, то он его распаковывает, пишет что-то типа “starting kernel…” и после этого компьютер перезагружается. Пробовал и обычный вариант и safemode - поведение аналогичное.

С тех пор были еще обновления, нынче версия уже 4.14.14 и картина прежняя. Последнее рабочее ядро было версии 4.14.9, на нем и сижу. В остальном система обновлена до упора, стоит Calculate Linux Desktop 17.12 Xfce. Все ядра и сама система - 32-битные. Я пока еще не проверял на одном ли только моем ноутбуке это проявляется (Dell Latitude, проц Intel Core i3-7100U) и только ли на этом варианте ядра такая ерунда - может, дело в несовместимых патчах и оригинальное будет получше, хотя в этом случае кто-нибуть это бы наверняка уже заметил. Пробовать gentoo-вское, чувствую, смысла вообще нет. Также, возможно что-то и с конфигом не то - я раньше cl-kernel-ом включал отключенную по умолчанию поддержку вебки через v4l. Хотя, это было еще до 4.14.9 и раньше все обновлялось до рабочего состояния. В общем, ясности пока нет, исследования продолжаются… Однако, если кто-то с подобным сталкивался и знает в чем может быть причина - было бы приятно услышать.

В остальном система обновлена до упора

Делать вам нечего :slight_smile: Я пока вообще залочил обновы ядра. Пусть уляжется пыль от последних новостей (у меня AMD).

Все ядра и сама система - 32-битные

И думаете тут много таких извращенцев?))

Загадка по прежнему существует, но появились новые данные. Опробованны ck-sources и ванильные ядра с тем же успехом. Также опробованно последнее longterm-ядро в calculate-варианте (версия 4.9.78) и оно грузится нормально и работает даже лучше чем 4.14.9 (которое живет, но при запуске ругается на что-то относительно поддержки ipv6). Таким образом проблема, как это ни удивительно, практически на 100% зарыта в ядре, варианты с кривой сборкой, initramfs, кривизной патчей и т.д. можно исключить. Тупо в версии 4.14.10 что-то такое поменяли относительно 4.14.9 что оно перестало работать с моим ноутом. Наверное это все последствия рождественских возлияний - зловредный патч был судя по всему заброшен в основной код ядра 29 декабря прошлого года. Похоже, остается пока сидеть на longterm-ядре и ждать пока главные разработчики пофиксят свежевнесенный глюк в новой версии…

Я пока вообще залочил обновы ядра. Пусть уляжется пыль от последних новостей (у меня AMD).

Не знаю, может оно и верно, но все же хочется всего самого свежего :slight_smile: А уж пользователям AMD так вроде и восе бояться нечего.

Все ядра и сама система - 32-битные
И думаете тут много таких извращенцев?))

Не знаю, думаю немало - все-таки много чего (почти все бинарное) под 32-мя битами работает гораздо лучше. WINE, например, насколько я знаю, под 64-битной системой нормально до сих пор не работает и не запускает 32-битные программы. Неужели теперь содержать зоопарк из обеих вариантов библиотек?

WINE, например, насколько я знаю, под 64-битной системой нормально до сих пор не работает …

Да, ради этого стоило переходить на линукс! Чтобы по-прежнему юзать вендовый софт)) Ну уж если очень нужно, то по моему проще поднять виртуалку, чем трахаться (другого слова мне не подобрать) с глючным кривым убогим вайном.
@ @
А так логи какие-нибудь нужно, вы же понимаете.

Не только вендовый, но и отпираченый нативный тоже канают! К тому же есть кое-какой, вендовый разумеется, софт, к которому давно нет исходников, но который все равно нужен для работы. Пробрасываешь виртуальный COM-порт в конфиге Wine и все работает.

Что касается логов, то в том то и беда, что в них записаться, похоже, ничего не успевает. Я проверил /var/log/messages - в нем новая инфа появлеятся только после зарузки живых ядер. Могу скинуть если это что-то прояснит, но единственно что там есть подозрительного - куча строчек вроде

Jan 24 13:35:33 CirillPortable kernel: pcieport 0000:00:1c.2: AER: Corrected error received: id=00e2
Jan 24 13:35:33 CirillPortable kernel: pcieport 0000:00:1c.2: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e2(Transmitter ID)
Jan 24 13:35:33 CirillPortable kernel: pcieport 0000:00:1c.2:   device [8086:9d12] error status/mask=00001000/00002000
Jan 24 13:35:33 CirillPortable kernel: pcieport 0000:00:1c.2:    [12] Replay Timer Timeout  

В /var/log/dmesg картина примерно та же, только строчка по поводу ошибок на шине pci express сейчас всего одна и лог полностью обновляется после каждой успешной перезагрузки.

Если есть еще какие-то логи, которые можно по этому поводу проверить и о которых я не знаю - было бы интересно узнать.

Пока сейчас картина такая, что GRUB свою работу выполняет и сразу же после система перезагружается, не успев даже на экране ничего по этому поводу нарисовать. UEFI у меня не используется.

В общем, на этом, похоже, пора остановиться. Нет, я слышал, что такое ядро тоже можно отлаживать с другого компьютера через последовательный порт (хотя у меня на ноуте его нету, а с USB-RS-232 адаптером фокус может не удастся - система тупо может не успеть не то что его поддержку подтянуть, а даже USB-хаб проинициализировать). Или можно скачать ванильное ядро и все патчи переводящие 4.14.9 в 4.14.10 и накладывать их по очереди пока не всплывет тот, от которого система умрет. Но это уже как-то перебор. Всякому мазохизму есть предел.

Последние изменения. Приехал домой и опробовал то же самое на своем компе (на базе топового AMD A10) и обновил систему на одной глубоко китайской таблетке (Intel Atom средней степени старости). На обоих последнее ядро работает точно так же (с теми же ошибками по поводу IPv6 в /var/log/dmesg), как и 4.14.9 и никаких безвременных перезагрузок, как и каких-либо других странностей не выявлено. Работает точно так же, как и все остальные 4.14 ядра. Так что, видимо, для выявления этого глюка нужен ноутбук на базе довольно свежей Intel-платформы, возможно даже что это - чисто DELL-овская особенность. Если кто сталкивался с такими эффектами и что-то знает - по прежнему прошу отписаться, но шансов, вероятно, немного. Так что пока посижу на стабильной версии и буду иногда пробовать запустится ли свежак. Если что новое обнаружится по данному вопросу - отпишусь.

Вот, прошло еще какое-то время, и тут случилось чудо. Вышло ядро 4.14.19, которое наконец тоже стало грузиться и даже на первый взгляд нормально работать, если только не один момент - под нагрузкой система периодически (в последний раз такое было после отработки команды git gc на одной из папок на флешке) подвисает на пару минут, не реагируя ни на нажатия клавиш клавиатуры ни на движения мышки. Если нажать волшебное SysRq+REISUB, то даже оно отработает только после того, как система отвиснет. В общем, пофиксить то они пофиксили, но тоже так себе… Правда, плюсом является то, что теперь в логах (/var/log/messages) есть отзвон об этой проблеме:
kernel: BUG: unable to handle kernel NULL pointer dereference at 00000008
kernel: IP: __radix_tree_lookup+0xe/0xa0
kernel: *pdpt = 000000000214a001 *pde = 0000000000000000
kernel: Oops: 0000 [#1] PREEMPT SMP

Дальше идет список подгруженных модулей, инфа о машине, версии ядра и BIOS-а, состояния регистров, развертка стека и кусок кода hex-ом из вызвавшего глюк места и еще куча всего малополезного. После этого уже снова идут сообщения по поводу дальнейшей работы. Единственное что из всей этой выдачи можно понять, что если начинать разбираться и рыть исходники, то начинать копать надо где-то в заголовочнике kernel/rcu/tree_plugin.h. Но делать этого я, разумеется, не собираюсь.

В общем, похоже, дело как-то сдвинулось и обновляться снова можно, но версия 4.9.78 (предполагаю, и вообще ветка 4.9) все равно работает намного стабильнее. На ней ничего такого не замечено. Если у кого-то такой-же аппарат - имейте в виду.

Таким образом на сегодняшний момент проблема решилась сама собой, но, если честно, я хоть и не так давно с Calculate, но вообще то в Linux не первый год (до этого долго сидел на Slackware, потом на MOPS, потом - Agilia до самой своей кончины) и с такими косяками прямо в ядре первый раз сталкиваюсь. То ли среди тамошних разработчиков реально какие-то нездоровые движения начались, то ли просто ноут я купил слишком новый и поддержка этих архитектур еще полностью не допилена (в пользу этого говорит то, что под новым ядром стало наконец нормально работать ускорение видео), то ли я чего-то не понимаю…

Да уж… никогда такого не было и вот опять…

Тот же ноут, та же система. Пришло на днях обновление ядра 5.4.4 и что бы вы думали? Снова похожие проблемы! Только на сей раз сразу после запуска ядра система не перезагружается, а заливает экран разноцветным полосатым мусором и зависает. Откатил до 4.19.89 (последнее доступное в calculate-sources из longterm-ветки 4.19) - на этой версии все прекрасно работает. И точно так же, проверил новое ядро на китайском сервере (х86) и домашней машине (64-бит) и на них с новым ядром ничего критичного не замечено.

Другие версии из 5-й ветки и ванильные ядра я уже на этот раз не пробовал - не вижу смысла утруждаться даже, поскольку в прошлый раз картина с ними была точь в точь аналогична первой установленной версии. Просто замаскировал >=sys-kernel/calculate-sources-5.0.0 и на том пока успокоился. Через полгодика где-то отключу и попробую новые ядра - может, пофиксят к тому времени.

В общем, проблемы по прежнему имеют место и решение для них прежнее. Если у вас такой же ноут - имейте в виду и не спешите обновляться на новую ветку.