remove-old-kernels оставляет только текущее ядро, удаляя все остальные: [root@localhost ~]# remove-old-kernels Running kernel version: kernel-image-std-def-2:5.10.123-alt1 Checking for installed kernel packages... For removing: kernel-image-std-def-5.10.118-alt1.x86_64 kernel-image-std-def-5.10.121-alt1.x86_64 Таким образом, если в работе текущего ядра обнаружатся проблемы, да еще и не сразу, то возможности загрузить предыдущее ядро уже не будет. И для исключения таких случаев remove-old-kernels должен оставлять предыдущее ядро. В данном примере должно удалиться только 5.10.118.
Идея хорошая, но... каким ядром пользовались до текущего не известно. Пользователь может ставить новые ядра, но не делать ребут (откладывая на потом и) оставаясь на более старом ядре чем предпоследнее.
только вести историю версий загрузки ядер. какую-то службу, которая каждый раз при загрузке пишет в текстовый файл/базу, какое ядро было загружено и когда.
Попробовал загружать предыдущие установленные ядра, и, смотрите, как интересно ведет себя скрипт: [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) > Задача "сделать чтоб было хорошо" не решалась так как она априори не решаемая. Почему? Главное её определить. А определить можно как "любым возможным образом оставить не менее двух ядер". Тогда вполне решаемо: в случае, если определить предпочтительное запасное не вышло, дополнительно оставить первое попавшееся.
