Возможно этот баг нужно перенести в к-л другую ветку, есть частично связанный баг https://bugzilla.altlinux.org/38888 однако он касается следствия, а не причины. Автоматически устанавливаемые из репозитория командой типа `update-kernel -t rt` ядра должны иметь ту же версию и по-возможности те же модули, что и ядро -std (по сути их нужно собирать одновременно с -std ядром). Экспериментальные версии ядер нужно держать отдельно и ставить с явным указанием номера версии. В противном случае мы получает неприятную ситуацию: -rt ядро имеет более новую версию и может не поддерживать имеющееся оборудования (например дисковые контроллеры). После чего при аварийном откате путём инсталляции предыдущего -std ядра система может перестать загружаться, что онсобенно неприятно на удалённой аппаратной серверной плтатформе.
1. Ядра могут иметь разные версии -- почему одно ядро должно иметь ту же версию, что и другое? Зачем тогда вообще держать другое ядро? 2. Что такое "экспериментальные версии ядер"? 3. Их "нужно держать отдельно" -- отдельно от чего? Не в Сизифе, а в другом репозитории? В каком? 4. Как установка rt ядра портит (откат на) std-def ядро?
IIUC человек пришёл с Debian(?), полагая, что единственный правильный путь -- как было там. После того(а не до), как уронил удалённый сервер, возникло такое видение проблемы. P.S. Вышенаписанное не в обиду, если что.
Другое (-rt) ядро нужно для того, чтобы проверить работоспособность серверной платформы для поддержки видео и аудиоконференций (могут быть и другие цели, я наткнулся на эту, там ещё спеиализированное оборудование подключено, до него дело не дошло). По сути комплект команд 1. update-kernel -t rt 2. installkernel обратно_на_std (мне уже не посмотреть, но каталог был правильный ;-) ) не должен приводить к полному окирпичиванию системы. -rt ядро в там виде как оно сейчас есть - экспериментальное, в нём отсутствует большое количество модулей (к примеру у меня не поднялся lsi sas дисковый контроллер). Для инсталляции такого ядра по-хорошему нужно в update-kernel указывать версию ядра, а не тип сборки. Это совместный баг скрипта update-kernel и комплекта ядер на репозитории. В результате update может привести внезапно к немедленной неработоспособности. Если делать совсем хорошо - то нужно предупреждать что новое ядро не поддерживает вот таких-то модулей, используемых в работающем сейчас. То, что откат при помощи installkernel приводит к тому, что сервер циклически перезагружается - видимо проблема installkernel.
update-kernel при установке другого ядра смотрит на модули текущего загруженного. Возможно, это надо доработать таким образом, что бы при указании типа ядра проверялось, стояло ли ранее ядро такого типа и списки дополнительных пакетов брались из установленного ранее ядра требуемого типа.
(Ответ для Igor Nikolaev на комментарий #3) > 2. installkernel обратно_на_std А где описано как использовать installkernel для возврата на старое ядро?
(Ответ для Anton Farygin на комментарий #4) > update-kernel при установке другого ядра смотрит на модули текущего > загруженного. > > Возможно, это надо доработать таким образом, что бы при указании типа ядра > проверялось, стояло ли ранее ядро такого типа и списки дополнительных > пакетов брались из установленного ранее ядра требуемого типа. Как я понял, речь не про дополнительные пакеты с модулями, а модули внутри пакета я ядром. Такая проверка (что устанавливаемое ядро содержит модули, которые сейчас загружены) конечно бы пригодилась!
(Ответ для Vitaly Chikunov на комментарий #5) > (Ответ для Igor Nikolaev на комментарий #3) > > 2. installkernel обратно_на_std > А где описано как использовать installkernel для возврата на старое ядро? https://www.altlinux.org/Grub "Как выбрать ядро для загрузки по умолчанию" Кирпич получен строго по инструкции ;-)
(Ответ для Sergey V Turchin на комментарий #2) > IIUC человек пришёл с Debian(?), полагая, что единственный правильный путь > -- как было там. После того(а не до), как уронил удалённый сервер, возникло > такое видение проблемы. > Вышенаписанное не в обиду, если что. Да какие там обиды, с Вашего позволения у человека ни в AIX, ни в SUNOS, ни в досточтимой SVR4 такого не было, так что ничего кроме лёгкой степени удивления ;-) По сути комплект команд, управляющий сменой ядра и базовых настроек специфичен для любого дистрибутива и должен быть по мере возможности максимально вычищен от KP и death strapping'а. Всё остальное чинится дистанционно, лишь ядра иногда умирают молча.
Igor, спасибо за ответ. Можете описать как именно старое ядро не загружается (какая ошибка возникает)? Я позже поэкспериментирую в виртуалке с установкой rt и возвратом на std-def. Но мне кажется это должно работать.
(In reply to Vitaly Chikunov from comment #9) > как именно старое ядро не загружается (какая ошибка возникает)? Возникает ошибка "нет связи с хостом", в том то и дело. P.S. Я не в курсе, что за ситуация с блокировкой IPMI, но это изначально ненормально, что она вообще возможна.
FYI: К слову, rt ядро не экспериментальное, но оно под конкретное оборудование на котором мы можем тестировать. Включать другие драйвера в нем вполне можно, если это не будет ухудшать его параметры. Скажите какую опцию вам включить и я включу в следующей версии этого ядра. CONFIG_MEGARAID_SAS?
Провел тесты в qemu виртуалке (в vml) -- проблема не подтвердилась. Описание теста: [root@alt-sisyphus ~]# uname -r 5.4.93-std-def-alt1 [root@alt-sisyphus ~]# apt-get update [root@alt-sisyphus ~]# apt-get install update-kernel -y [root@alt-sisyphus ~]# update-kernel -t rt -f [root@alt-sisyphus ~]# reboot [root@alt-sisyphus ~]# uname -r 5.10.104-rt-alt1.rt63 [root@alt-sisyphus ~]# installkernel 5.4.93-std-def-alt1 [root@alt-sisyphus ~]# reboot [root@alt-sisyphus ~]# uname -r 5.4.93-std-def-alt1
По поводу усовершенствования update-kernel можно завести отдельный баг. (Я пока записал себе в todo.)
(In reply to Vitaly Chikunov from comment #6) > Такая проверка (что устанавливаемое ядро содержит модули, > которые сейчас загружены) конечно бы пригодилась! Похоже, (в рамках apt-rpm) такую проверку невозможно сделать, так как установка ядра происходит обычным `apt-get install` и предварительного доступа к rpm (для анализа его содержания) нет.
Да, и в pkglist списка модулей тоже нет. Так что такое представляется возможном только как внешний (http) сервис, а значит не все смогут им пользоваться. ps. Как раз собираю сегодня новое rt ядро и раз CONFIG_MEGARAID_SAS не нужен, то я его не включаю.
(Ответ для Vitaly Chikunov на комментарий #9) > Igor, спасибо за ответ. Можете описать как именно старое ядро не загружается > (какая ошибка возникает)? Я позже поэкспериментирую в виртуалке с установкой Прислали видео экрана загрузки. Раз в пять секунд прмерно на две десятых секунды мигает картинка: http://voip.pu.ru/20220317.png (снапшот выдрал из видео). Увы, но эта картинка промигивает также при обычной загрузке. Это российский сервер Рикор R-S-2-XEONGOLD6133, сертифицированный во все дыры. В итоге sdd с печальным результатом заменён на новый, на досуге посмотрю что там в .bashhistory. К сожалению по умолчанию прописан quiet в grub.cnf, так что ядро паникует молча. Где оно падает не видно.
(Ответ для Vitaly Chikunov на комментарий #12) > Провел тесты в qemu виртуалке (в vml) -- проблема не подтвердилась. Описание > [root@alt-sisyphus ~]# uname -r > 5.4.93-std-def-alt1 > [root@alt-sisyphus ~]# apt-get install update-kernel -y Я сначала делал update-kernel без параметров, получил -std ядро (5.10.102, а потом уже сделал update до rt. > [root@alt-sisyphus ~]# update-kernel -t rt -f > [root@alt-sisyphus ~]# reboot > > [root@alt-sisyphus ~]# uname -r > 5.10.104-rt-alt1.rt63 > [root@alt-sisyphus ~]# installkernel 5.4.93-std-def-alt1 И соответственно здесь падал обратно до 102 > [root@alt-sisyphus ~]# reboot Вот .bash_history (без разных там df, ls, установки MegaCli lxde-lxdm и прочего с ядром несвязанного) apt-get update apt-get dist-upgrade update-kernel update-kernel -t rt reboot далее две команды могли на что-то повлиять (вряд ли, но для комплекта) apt-get remove virtualbox-common apt-get -y install kernel-modules-zfs-std-def reboot всё норм перегрузилось. Вошёл под пользователем, решил вернуться на -std: sudo installkernel 5.10.102-std-def-alt1 update-kernel -l sudo reboot и получился кирпич. Возможно (скорее всего) я что-то делал неверно. Ничего страшного, но хочется понять где кроме днк ошибка ;-)
Попробовал по вашему сценарию, система загрузилась успешно: # uname -r 5.4.93-std-def-alt1 # apt-get update; apt-get install update-kernel -y # apt-get dist-upgrade # update-kernel # -> 5.15.29-std-def-alt1 # update-kernel -t rt # -> 5.10.104-rt-alt1.rt63 # reboot # uname -r 5.10.104-rt-alt1.rt63 # apt-get -y install kernel-modules-zfs-std-def # installkernel 5.15.29-std-def-alt1 # <- новое std-def ядро # reboot # uname -r 5.15.29-std-def-alt1 # modprobe zfs # ls -l /boot total 60308 -rw-r--r-- 1 root root 258 Jan 28 2021 boot.conf -rw-r--r-- 1 root root 215263 Mar 11 00:28 config-5.10.104-rt-alt1.rt63 -rw-r--r-- 1 root root 251672 Mar 16 18:00 config-5.15.29-std-def-alt1 -rw-r--r-- 1 root root 230563 Jan 28 2021 config-5.4.93-std-def-alt1 drwxr-xr-x 5 root root 4096 Mar 19 00:25 grub -rw------- 1 root root 7644439 Mar 19 00:24 initrd-5.10.104-rt-alt1.rt63.img -rw------- 1 root root 8075010 Mar 19 00:27 initrd-5.15.29-std-def-alt1.img -rw------- 1 root root 8286917 Jan 28 2021 initrd-5.4.93-std-def-alt1.img lrwxrwxrwx 1 root root 31 Mar 19 00:27 initrd.img -> initrd-5.15.29-std-def-alt1.img lrwxrwxrwx 1 root root 32 Mar 19 00:24 initrd-rt.img -> initrd-5.10.104-rt-alt1.rt63.img lrwxrwxrwx 1 root root 31 Mar 19 00:27 initrd-std-def.img -> initrd-5.15.29-std-def-alt1.img -rw-r--r-- 1 root root 4058636 Mar 11 00:28 System.map-5.10.104-rt-alt1.rt63 -rw-r--r-- 1 root root 5029739 Mar 16 18:00 System.map-5.15.29-std-def-alt1 -rw-r--r-- 1 root root 3688002 Jan 28 2021 System.map-5.4.93-std-def-alt1 lrwxrwxrwx 1 root root 28 Mar 19 00:27 vmlinuz -> vmlinuz-5.15.29-std-def-alt1 -rw-r--r-- 1 root root 10731896 Mar 11 00:49 vmlinuz-5.10.104-rt-alt1.rt63 -rw-r--r-- 1 root root 7848984 Mar 16 18:32 vmlinuz-5.15.29-std-def-alt1 -rw-r--r-- 1 root root 5657568 Jan 28 2021 vmlinuz-5.4.93-std-def-alt1 lrwxrwxrwx 1 root root 29 Mar 19 00:24 vmlinuz-rt -> vmlinuz-5.10.104-rt-alt1.rt63 lrwxrwxrwx 1 root root 28 Mar 19 00:27 vmlinuz-std-def -> vmlinuz-5.15.29-std-def-alt1 Значит это рабочая схема.
(Ответ для Vitaly Chikunov на комментарий #15) > Да, и в pkglist списка модулей тоже нет. Так что такое представляется > возможном только как внешний (http) сервис, а значит не все смогут им > пользоваться. Я теперь снова думаю, что это может быть теоретически возможным, если сначала update-kernel бы запускал apt-get install с --download-only (как при --dry-run), затем проверял пакеты я ядром из /var/cache/apt/archives на совместимость (другой сложный вопрос), затем те же apt-get install с --no-download.
Железный сервер отличается от виртуалки тем, что он по reboot может через некоторое время мигнуть питанием. Может где-то что-то типа sync && sync недоделано? В качестве boot диска там был ssd mz-7kh4800. Собственно диск у меня на выноску подключен, там поназаписано 6G разного, если продолжать искать то я могу либо выложить куда-то содержимое (по nfs чтобы не пересылать кирпичи почтой ;-) ) либо прислать конкретные файлы (логи к примеру) либо "могу повторить" со вторым новым таким же диском на этом сервере (увы, но это один из немногих нонче сертифицированных российских производителей, мне его на следующей неделе запустить нужно). Вставлять диск в другую коробку не рискую - а вдруг там всё заработает и эффект исчёзнет. Уж извините, я так и не понял куда alt по умолчанию кладёт что-нибуть типа kern.log, messages, syslog итп чтобы посмотреть "что это было".
reboot должен делать sync. По журналу загрузки: # journalctl --list-boots -1 91b095d038cb4fcaab18276b58a88b07 Sat 2022-03-19 04:33:23 UTC—Sat 2022-03-19 04:33:50 UTC 0 4fbcda8bd4f74d75bf8163baa266586c Sat 2022-03-19 04:34:00 UTC—Sat 2022-03-19 05:04:51 UTC Затем в `journalctl --boot=` указать id из первого столбца.
