Bug 53849 - remove-old-kernels иногда не предлагает резервные (backup) версии ядер
Summary: remove-old-kernels иногда не предлагает резервные (backup) версии ядер
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: update-kernel (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 enhancement
Assignee: Vitaly Chikunov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-04-15 13:51 MSK by Сергей Сысоев
Modified: 2025-04-16 06:47 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 дня, но в случае, если таких не нашлось, как запасной вариант оставлять хотя бы предпоследнее.

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