53849 2025-04-15 13:51:05 +0300 remove-old-kernels иногда не предлагает резервные (backup) версии ядер 2025-04-16 06:47:05 +0300 1 1 4 Development Sisyphus update-kernel unstable x86_64 Linux NEW P5 enhancement --- 1 sysoevsa vt boyarsh evg lav mike sysoevsa vt qa-sisyphus oldest_to_newest 262992 0 sysoevsa 2025-04-15 13:51:05 +0300 Добрый день. Иногда 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). 262993 1 sysoevsa 2025-04-15 13:52:26 +0300 Или если вычисляется, что версия backup==booted, то также лучше оставлять предпоследнее, не загруженное. (Backup kernel is the same as booted kernel (uptime 14 days).) 263023 2 vt 2025-04-15 17:20:11 +0300 Дело в том что "предпоследние" ядра -- не резервные. Резервное ядро - которое было успешно загружено и up в течении суток и более. 263065 3 sysoevsa 2025-04-16 06:47:05 +0300 Виталий, выскажу свои мысли. По первому примеру: ># 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 дня, но в случае, если таких не нашлось, как запасной вариант оставлять хотя бы предпоследнее. Лучше иметь хоть одно запасное ядро, чем вообще не иметь никаких.