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

только вести историю версий загрузки ядер.
какую-то службу, которая каждый раз при загрузке пишет в текстовый файл/базу, какое ядро было загружено и когда.

Попробовал загружать предыдущие установленные ядра, и, смотрите, как интересно ведет себя скрипт:

[root@localhost ~]# remove-old-kernels
Running kernel version: kernel-image-std-def-2:5.10.121-alt1
Checking for installed kernel packages...
For removing:
  kernel-image-std-def-5.10.118-alt1.x86_64


[root@localhost ~]# remove-old-kernels
Running kernel version: kernel-image-std-def-2:5.10.118-alt1
Checking for installed kernel packages...
For removing:

Nothing to remove.

То есть ядра, старше текущего, не рассматриваются! :) В таком случае, остается подправить, чтобы не удалялось ядро с максимальной версией из получаемого списка. В смысле, после получения списка удалить в нем максимальное значение.

Не старше текущего, а моложе, конечно :) Более новой версии.

Если важно, какие ядра были недавно загружены, можно смотреть в
вывод программы last -a reboot .

Created attachment 10983 [details]
remove-old-kernels.new для тестирования

Comment on attachment 10983 [details]
remove-old-kernels.new для тестирования

см. строки 98-116

Спасибо, команда last -a reboot интересная, но если учитывать предыдущее загруженное ядро, придется весь код переписывать, я в этом пока не силен :) Посмотрел код, насколько понял, остаются текущее и новые ядра из текущего flavour и последние из других flavours. Чтобы сильно не менять алгоритм, дописал определение предыдущего ядра относительно текущего для текущего flavour и исключение этого предыдущего ядра и новее из выбора ядер для удаления. Файл вложил, смотреть строки 98-116. Может, код не очень красиво выглядит из-за повтора цикла, но работает :)

1. Сейчас поведение remove-old-kernels понятное, и его нужно запускать после успешной загрузки в новое ядро, после того как вы убедились, что проблем нет.
2. Как я уже сказал, просто предыдущая версия не гарантирует даже 99% что это предыдущее загруженное или предыдущее рабочее ядро. Вам повезло что это оказалась та версия что вам нужна, а другим людям не повезёт. Зачем реализовывать логику которая не дает и 1% гарантий не понятно.
3. `last -a reboot` интересный вариант. Видимо нужно выбирать ядро, которое проработало минимум 1 день.

 5.15.48-std-def-alt1:~# last -a reboot -22
 reboot   system boot  Sun Jun 26 05:17 - 05:24  (00:06)     5.15.48-std-def-alt1
 reboot   system boot  Sun Jun 26 05:06 - 05:16  (00:09)     5.18.6-un-def-alt2
 reboot   system boot  Sun Jun 26 05:00 - 05:05  (00:05)     5.18.6-un-def-alt2
 reboot   system boot  Sun Jun 26 04:35 - 04:59  (00:23)     5.15.48-std-def-alt1
 reboot   system boot  Sun Jun 26 04:31 - 04:34  (00:02)     5.18.6-un-def-alt2
 reboot   system boot  Sun Jun 26 04:28 - 04:30  (00:02)     5.18.6-un-def-alt2
 reboot   system boot  Fri Jun 24 03:54 - 04:30 (2+00:36)    5.18.6-un-def-alt2
 reboot   system boot  Thu Jun 23 20:02 - 03:53  (07:51)     5.18.6-un-def-alt1
 reboot   system boot  Wed Jun 22 03:59 - 20:00 (1+16:01)    5.15.48-std-def-alt1
 reboot   system boot  Wed Jun 22 03:45 - 03:57  (00:12)     5.15.48-std-def-alt1

Тут ядро это 5.18.6-un-def-alt2 так как оно работало 2 дня. Первое ядро с "+" в 10 столбце.

 5.15.48-std-def-alt1:~# last -a reboot | awk '$10~/+/{print$11;exit}'
 5.18.6-un-def-alt2

update-kernel-1.3-alt1 -> sisyphus:

 Sun Jun 26 2022 Vitaly Chikunov <vt@altlinux> 1.3-alt1
 - remove-old-kernels: Show list of kernel that won't be removed and why.
 - remove-old-kernels: Add colors to improve UI (for a dark background).
 - remove-old-kernels: Do not remove previous kernel with good uptime (backup
   kernel) as safeguarding measure. (ALT#43062)
 - remove-old-kernels: Slightly change confirmation logic (do not leave
   confirmation to apt-get.)
 - remove-old-kernels: Add -A option to attempt to remove other flavours
   completely (which was previously impossible).

Сделал экспериментальную поддержку backup ядра (из "last -a reboot"). До кучи попробовал улучшить UI у remove-old-kernels.

(In reply to Alexander Kovalev from comment #0)

> Таким образом, если в работе текущего ядра обнаружатся проблемы, да еще и не
> сразу, то возможности загрузить предыдущее ядро уже не будет. И для
> исключения таких случаев remove-old-kernels должен оставлять предыдущее
> ядро. В данном примере должно удалиться только 5.10.118.

Вообще, до этого момента, я просто запускал remove-old-kernels до обновления ядра, оставляя одно то, которое давно работало.

(In reply to Vitaly Chikunov from comment #11)

> Сделал экспериментальную поддержку backup ядра (из "last -a reboot"). До
> кучи попробовал улучшить UI у remove-old-kernels.

Интересный вариант, но несколько не доработан. 

Случай 1:

# remove-old-kernels
Currently booted kernel package: kernel-image-std-def-4.9.267-alt0.M80P.1
Backup kernel is the same as booted kernel (uptime 9 days).
Not removing this kernel (with the reason why):
   kernel-image-std-def-4.9.267-alt0.M80P.1 (latest for std-def, currently booted)

Will be removing this kernel:
   kernel-image-std-def-4.9.240-alt0.M80P.1

Запасным ядром выбирается работающее, и реально запаса не остаётся.

Случай 2:

# remove-old-kernels
Currently booted kernel package: kernel-image-std-def-4.9.319-alt0.M80P.1
Warning: Backup kernel is not determined.
Not removing this kernel (with the reason why):
   kernel-image-std-def-4.9.319-alt0.M80P.1 (latest for std-def, currently booted)

Will be removing these 3 kernels:

"last -a reboot" не выводит искомых строк (кстати, отдельно интересно почему), и опять не остаётся ни одного запасного ядра. 

В общем в случае, когда что-то непонятно, всё равно надо оставлять второе ядро, если есть, что оставлять.

(In reply to Sergey Y. Afonin from comment #13)

> Случай 1:
> 
> # remove-old-kernels
> Currently booted kernel package: kernel-image-std-def-4.9.267-alt0.M80P.1
> Backup kernel is the same as booted kernel (uptime 9 days).
> Not removing this kernel (with the reason why):
>    kernel-image-std-def-4.9.267-alt0.M80P.1 (latest for std-def, currently
> booted)
> 
> Will be removing this kernel:
>    kernel-image-std-def-4.9.240-alt0.M80P.1
> 
> Запасным ядром выбирается работающее, и реально запаса не остаётся.

И, кстати, это сам по себе баг, если расчёт по максимальному количеству дней:

# rpm -qa| grep kernel-im
kernel-image-std-def-4.9.267-alt0.M80P.1
kernel-image-std-def-4.9.240-alt0.M80P.1

# last -a reboot
reboot   system boot  Mon Sep 12 19:57 - 12:41 (9+16:44)    4.9.267-std-def-alt0.M80P.1
reboot   system boot  Sat Dec  5 05:31 - 12:41 (656+07:09)  4.9.240-std-def-alt0.M80P.1
reboot   system boot  Mon Oct 19 12:14 - 05:29 (46+17:15)   4.9.239-std-def-alt0.M80P.1
reboot   system boot  Tue Aug 27 17:40 - 12:12 (418+18:31)  4.9.188-std-def-alt0.M80P.1

4.9.240-alt0.M80P.1 явно должно получиться кандидатом на бакап. Хотя если выбирается просто первое ядро с +, то так оно и есть, так как текущее 9+. И ещё момент надо, видимо, учитывать: last -a reboot может выводить список с ядрами, которых уже нет, и максимальное время может оказаться у отсутствующих ядер.

remove-old-kernels сейчас "берет последнее ядро с uptime больше суток". Это может быть то же самое ядро что уже загружено. Это не баг и "не недоработанное", а детерминированное понятнее поведение. Задача "сделать чтоб было хорошо" не решалась так как она априори не решаемая.

(In reply to Vitaly Chikunov from comment #15)

> Задача "сделать чтоб было хорошо" не решалась так как она априори не решаемая.

Почему? Главное её определить. А определить можно как "любым возможным образом оставить не менее двух ядер". Тогда вполне решаемо: в случае, если определить предпочтительное запасное не вышло, дополнительно оставить первое попавшееся.