Bug 53849

Summary:	remove-old-kernels иногда не предлагает резервные (backup) версии ядер
Product:	Sisyphus	Reporter:	Сергей Сысоев <sysoevsa>
Component:	update-kernel	Assignee:	Vitaly Chikunov <vt>
Status:	NEW ---	QA Contact:	qa-sisyphus
Severity:	enhancement
Priority:	P5	CC:	boyarsh, evg, lav, mike, sysoevsa, vt
Version:	unstable
Hardware:	x86_64
OS:	Linux

Description

Сергей Сысоев 2025-04-15 13:51:05 MSK

Добрый день.

Иногда remove-old-kernels не предлагает оставить ни одной резервной версии ядер. Примеры:
1.
># remove-old-kernels 
>Currently booted kernel package: kernel-image-un-def-6.1.131-alt1
>Backup kernel is the same as booted kernel (uptime 14 days).
>Keeping this kernel (with the reason why):
>   kernel-image-un-def-6.1.131-alt1.x86_64 (latest for un-def, currently booted)
>
>Will be removing this kernel:
>   kernel-image-un-def-6.1.121-alt1.x86_64
>
>Confirm uninstall action for this kernel [Y/n]? n

2.
># remove-old-kernels 
>Currently booted kernel package: kernel-image-un-def-6.1.131-alt1
>Warning: Backup kernel is not determined.
>Keeping this kernel (with the reason why):
>   kernel-image-un-def-6.1.131-alt1.x86_64 (latest for un-def, currently booted)
>
>Will be removing these 4 kernels:
>   kernel-image-un-def-6.1.79-alt1.x86_64
>   kernel-image-un-def-6.1.99-alt1.x86_64
>   kernel-image-un-def-6.1.112-alt1.x86_64
>   kernel-image-un-def-6.1.121-alt1.x86_64
>
>Confirm uninstall action for these 4 kernels [Y/n]? 

Было бы лучше, что если не удается вычислить бекапное ядро (Warning: Backup kernel is not determined), то оставлялось бы просто предпоследнее, не загруженное.

Для удаления всех ядер, если кому надо, всегда есть ключик:
-B, --no-backup   Disable logic which keeps backup kernel (i.e. remove it too).

Comment 1

Сергей Сысоев 2025-04-15 13:52:26 MSK

Или если вычисляется, что версия backup==booted, то также лучше оставлять предпоследнее, не загруженное.

(Backup kernel is the same as booted kernel (uptime 14 days).)

Comment 2

Vitaly Chikunov 2025-04-15 17:20:11 MSK

Дело в том что "предпоследние" ядра -- не резервные. Резервное ядро - которое было успешно загружено и up в течении суток и более.

Comment 3

Сергей Сысоев 2025-04-16 06:47:05 MSK

Виталий, выскажу свои мысли.

По первому примеру:

># last -a reboot
>reboot   system boot  Tue Apr  1 13:29 - 08:19 (14+18:49)   6.1.131-un-def-alt1
>reboot   system boot  Tue Apr  1 13:24 - 13:29  (00:04)     6.1.121-un-def-alt1
>reboot   system boot  Tue Feb  4 12:12 - 13:22 (56+01:10)   6.1.121-un-def-alt1
>reboot   system boot  Mon Jan 27 14:25 - 12:11 (7+21:46)    6.1.121-un-def-alt1
>reboot   system boot  Tue Jan 21 13:39 - 14:25 (6+00:46)    6.1.121-un-def-alt1

Но в good_kernel попадает текущее ядро, так как у него больше 1 дня аптайм:
># good_kernel=$(LC_ALL=C last -a reboot | awk '$ 10 ~ /+/ {print $10,$11; exit }')
># echo $good_kernel
>(>14+18:51) 6.1.131-un-def-alt1

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


По второму примеру в логах вообще только одно ядро, так как на сервере включен расширенный аудит, и логи забиваются этим аудитом (вычищая записи с reboot), хотя по аптайму ядер там примерно также как с предыдущим примером:
># last -a reboot
>reboot   system boot  Tue Apr 15 09:03 - 08:19  (23:16)     6.1.131-un-def-alt1

И тогда remove-old-kernels не предлагает вообще ни одного запасного ядра.

Понятно, что лучший вариант, оставлять ядро, у которого аптайм >1 дня, но в случае, если таких не нашлось, как запасной вариант оставлять хотя бы предпоследнее.

Лучше иметь хоть одно запасное ядро, чем вообще не иметь никаких.