Today (yesterday), maybe for the third time this year, I saw someone asking how to remove old kernels. But, the answer today was interesting ! One of our Mageian develop a shell-script, with a dry-run mode, the number of most recent kernels to keep. (I asked and he approves : https://ml.mageia.org/l/arc/discuss-fr/2019-02/msg00119.html ) Here is the script in attachment : https://ml.mageia.org/l/arc/discuss-fr/2019-02/msg00113.html Is it possible to add it in our control-center ?
Created attachment 10776 [details] Pierre Jarillon's remove-old-kernels script Thanks for telling about the script. It would be nice to have a GUI for it, like all our MCC tools have.
CC: (none) => marja11
(In reply to Marja Van Waes from comment #1) > Created attachment 10776 [details] > Pierre Jarillon's remove-old-kernels script > > Thanks for telling about the script. > > It would be nice to have a GUI for it, like all our MCC tools have. If it can't be added to MCC, then maybe the people working on the Mageia Panel tools can add it there, CC'ing them.
CC: (none) => anaselli, ngompa13, yves.brungard_mageiaSummary: Feature request : removing old kernels => Feature request : tool to remove old kernelsAssignee: bugsquad => mageiatools
Well dnf should do the tricks but it seems our kernel versioning is not working for that. Command should be dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q) Unfortunately "dnf repoquery --installonly --latest-limit=-2" seems to fail using --latest-limit=-2 because kernel package has a fake versioning way. Maybe tmb could something on that.
That to say that if i added something for that on dnfdragora, only other distro could use it...
Just as a suggestion, wouldn't it be better to have a limit of 3 installed kernels and when there is a new kernel to install the oldest of the installed kernels would be uninstalled?
CC: (none) => hamnisdude
what if the 3 latest does not work and i need to use the 4th ? I already saw this situation so this is not a good one for me
CC: (none) => mageia
@Nicolas, if you have a non working kernel you could also remove it and leave the last working on top. But I see we are talking of normal users... @Kristoffer, mine was an example to limit at 2. dnf allows to set that into its configuration file to the preferred number. But since we have the fake ver issue (or choice it depends on POW) we cannot use it.
@angelo: i need to make a bugreport for a friend in mga6 with this issue ( non booting kernel but previous is ). For me automagically removing old kernel is dangerous, i prefer a user action.
@neoclust: This is actually fully configurable. While DNF defaults to keeping the three latest, you can increase the number or even disable the autoremoval entirely: https://dnf.readthedocs.io/en/latest/conf_ref.html#installonlypkgs-label So it's really in your control, it just gives a good reasonable default for most people.
Created attachment 10860 [details] Another script to remove old packages such as kernels installed by a "latest" package Wrote this script yesterday in response to a similar request. Wasn't aware of this bug report or existing script at the time.
CC: (none) => davidwhodgins
(In reply to Angelo Naselli from comment #3) > Well dnf should do the tricks but it seems our kernel versioning is not > working for that. > > Command should be > > dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q) > doesnt work here. nothing to do finish but dnf repoquery --installonly tell me kernel-server-5.1.1-1.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.2-1.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.3-4.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.3-5.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.3-6.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.4-1.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.5-1.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.6-1.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.7-1.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.7-2.mga7-0:1-1.mga7.x86_64 kernel-server-5.1.8-1.mga7-0:1-1.mga7.x86_64
CC: (none) => dieter
(In reply to Dieter Schütze from comment #11) > (In reply to Angelo Naselli from comment #3) > > Well dnf should do the tricks but it seems our kernel versioning is not > > working for that. > > > > Command should be > > > > dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q) > > > > doesnt work here. > nothing to do > finish > but > dnf repoquery --installonly > tell me > kernel-server-5.1.1-1.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.2-1.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.3-4.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.3-5.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.3-6.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.4-1.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.5-1.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.6-1.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.7-1.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.7-2.mga7-0:1-1.mga7.x86_64 > kernel-server-5.1.8-1.mga7-0:1-1.mga7.x86_64 It's not working quite right because from DNF's point of view, there's only one of each. We do some mangling to the kernel package name and version-release so it's not able to correctly identify it as the same kind of package. This is fixable, but that's up to tmb if we want to do that now. I'd like to see us make the switch in Mageia 8...
This only works if you have only kernels of one flavor (server, desktop) urpme $(rpm -qa|grep kernel-$(uname -r|cut -d '-' -f2)|grep -v $(uname -r|cut -d '-' -f1))
I think this should be elevated in priority and severity as it is now breaking systems for regular non-tech users. Yesterday my brother-in-law dropped of his laptop for my attention as it would no longer update. It has been running Mageia 6 from around initial release with 20GB of / partition. He only runs a few programs mainly browsers and kodi. Updates were failing due to lack of space in /. To fix it I had to remove ~42 kernels, kernel-desktop-devels and vbox kernels (not sure why they were there as vbox is not installed). Now 50% of / is again free. It was installed from a live originally. Talk of dnf and scripts would go right over his head. A default, sensible limit is required in stable releases that works out of the box without user intervention.
CC: (none) => zen25000
at the past urpme --auto-orphans removes old kernels if they are not blocked in the config.
(In reply to Dieter Schütze from comment #15) > at the past urpme --auto-orphans removes old kernels if they are not blocked > in the config. Yes, but regular users doing updates are no longer encouraged to use urpme --auto-orphans. In the case I outlined above the user in question has never used a command line tool or a terminal, as is the case with many Windows/Mac users. A system that breaks itself after 12 months just because the user followed GUI prompts to do updates is critically flawed. Changing from enhancement to normal bug.
Severity: enhancement => normal
That is critical. If a normal user only work with gui and the old kernel never remove you get a full /boot disk. Mageia don't check the disk space of the partition with the kernels. Or has this changed now ? And of course i am a normal user. Never do a gui on the Serversystem ;) Or is Mageia not to use for (as) Serversystems ?
I think there should be no separate method for this - most users will not remember to use it. Maybe we better at any package install/update session detect if removal is needed, and then pop up a dialog to inform the user? i.e count number of installed kernels, and allow less installed when there is less room *) . And check both / , and - if a separate partition - also /boot. *) Consider the space as it will be *after* update/install (we seem to already calculate how much more disk space will be used. Maybe create the command "urpme --auto-kernels" With some optional parameter for number of kernels or similar. Could be used manually, or with a [Do it now] button in said dialog.
CC: (none) => fri
After reading Bug 22675, bug reporter's situation misbehave when too many kernels in /boot and with other Mageia installations on same disk. While this situation is not supported well by our tools, there are drawbacks holding this situation. We can't support every some particular use of our distribution with multiple instances on same harddrive, but we should prevent /boot from being messed up by too many kernels, initrd, config, here. GRUB does his job populating his menu after every kernel release, but, during lifetime of a release, we publish some updates and new versions of Linux kernel in order to enable new hardware, correct bugs and address security vulnerability in such crucial component. But: end-users should not see too much Kernel's images in their /boot. Too many bugs could occurs, and we should not allow booting vulnerable kernels. I think hold "n-1" after updating could be correct and it allows our users to reboot on n-1 kernel if something goes wrong with new one. This is a stopgap and we need to uninstall the old kernels a week after the update, while leaving them in the repositories for urgent reinstallation. Having situation in Comment 14 must not be repeated.
Severity: normal => majorCC: (none) => ouaurelienBlocks: (none) => 22675Priority: Normal => High
Hi, This is High priority bug for a good reason. Making Mageia even better than ever is best direction. In order to do right thing, this bug should be examined and fixed as soon as possible. Packagers, please make the status to Assigned when you are working on this. Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it. On October 1st 2020, we will drop priority to normal.
I add a first try to solve this in http://ftp.blogdrake.net/mageia/mageia7/free/noarch/Tuningdrake-2.2.3-2bdk.mga7.noarch.rpm now contain a script named kernel-clean, by default it list the old kernel-<old-version>, kernel-devel-<old-version> packages and you can choose what you want to uninstall But if run kernel-clean --auto It should remove all the old ld kernel-<old-version>, kernel-devel-<old-version> packages It must be run as root of course
(In reply to Aurelien Oudelet from comment #19) > > I think hold "n-1" after updating could be correct and it allows our users > to reboot on n-1 kernel if something goes wrong with new one. This is a > stopgap and we need to uninstall the old kernels a week after the update, > while leaving them in the repositories for urgent reinstallation. I disagree. Too microsoftie for my taste. I use xmessage to pop up a yellow background message with the urpme kernelxxxxx lines to let the user decide to remove them or not. Your suggestion to automagically delete old kernels will irritate users with a common uefi /boot partition with mga5, mga6, mga7, cauldron installs. Also a danger to users with old video hardware and want/need old kernel. > Having situation in Comment 14 must not be repeated. Then modify drakrpm-update to do a (download rpms size total times 3) free space check prior to install and require user to free up some space and abort the install. You might want to modify rpmdrake to do same test. dnf needs the same tests.
CC: (none) => bittwister2
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=27998
Please see also https://wiki.mageia.org/en/Feature_Talk:Limit_number_of_installed_kernels The suggested N=0 option would enable those who want lots of kernels to have them. Comment 14 is very relevant - I too have to support users who run out of space on /boot so updates fail and they then start to question whether Mageia is right for them. In addition, there are ~20 machines at a non-profit computer group for which I am responsible. These are ex thin clients and therefore have small boot disks. It would be much easier if Mageia had built-in kernel ageing rather than my having to deploy scripts and update these when a new version of Mageia comes along.
urpme --auto-orphans has the logic to remove kernel, it seems people don't want that but only kernels so that part should be extracted. For users of GUI http://gitweb.mageia.org/software/rpmdrake/commit/?id=69b6ad5a9f8e3fc4c1e44d14857787e834386311 could be then be reverted but only for kernels. I guess we would need a new option (--auto-kernel-orphans ?).
CC: (none) => pterjan
For reference, the existing logic is at http://gitweb.mageia.org/software/rpm/urpmi/tree/urpm/orphans.pm#n477 (it keeps latest kernels + the currently used one as this one is known to work).
IIUC the code, there is a need to first call _kernel_callback in order to fill the @req_by_latest_kernels var so that we can then call _get_orphan_kernels Then we need to pass the right arams to that _kernel_callback which I have not tracked up to now. I may be able to look at that if at least my understanding upper is correct.
CC: (none) => bruno
Hi all! I noticed that if I manually uninstall the previous kernels, smoothly listing urpme oldkernel1 oldkernel2, update-grub will run after each kernel removed. Maybe you should consider running it once at the very end. He didn't take the devel packages with him.
CC: (none) => pingvin
(In reply to Jybz from comment #0) > Today (yesterday), maybe for the third time this year, I saw someone asking > how to remove old kernels. > > But, the answer today was interesting ! > > One of our Mageian develop a shell-script, with a dry-run mode, the number > of most recent kernels to keep. > (I asked and he approves : > https://ml.mageia.org/l/arc/discuss-fr/2019-02/msg00119.html ) > > Here is the script in attachment : > https://ml.mageia.org/l/arc/discuss-fr/2019-02/msg00113.html > > Is it possible to add it in our control-center ? I can confirm this scripts still works in Mageia 7, the default is to keep the two latest kernels. The script also found and listed orphaned files: ./remove-old-kernels ==> kernel-desktop 1 : keep : kernel-desktop-5.10.20-2.mga7-1-1.mga7.x86_64 Mon 08 Mar 2021 07:52:20 GMT 2 : keep : kernel-desktop-5.10.19-1.mga7-1-1.mga7.x86_64 Fri 05 Mar 2021 02:13:11 GMT 3 : remove : kernel-desktop-5.10.14-1.mga7-1-1.mga7.x86_64 4 : remove : kernel-desktop-5.10.12-1.mga7-1-1.mga7.x86_64 Remove 2 kernels ? y/N y removing kernel-desktop-5.10.14-1.mga7-1-1.mga7.x86_64 removing package kernel-desktop-5.10.14-1.mga7-1-1.mga7.x86_64 1/1: removing kernel-desktop-5.10.14-1.mga7-1-1.mga7.x86_64 ###################################################################################################################################################### need_removing_empty_extended The following packages: lib64filezilla0-0.16.0-1.mga7.x86_64 lib64ixion0.14_0-0.14.1-2.mga7.x86_64 lib64magick-7Q16HDRI_6-7.0.8.62-1.mga7.tainted.x86_64 lib64orcus0.14_0-0.14.1-2.mga7.x86_64 lib64startup-notification1_0-0.12-11.mga7.x86_64 are now orphaned, if you wish to remove them, you can use "urpme --auto-orphans" removing kernel-desktop-5.10.12-1.mga7-1-1.mga7.x86_64 removing package kernel-desktop-5.10.12-1.mga7-1-1.mga7.x86_64 1/1: removing kernel-desktop-5.10.12-1.mga7-1-1.mga7.x86_64 ###################################################################################################################################################### need_removing_empty_extended The following packages: lib64filezilla0-0.16.0-1.mga7.x86_64 lib64ixion0.14_0-0.14.1-2.mga7.x86_64 lib64magick-7Q16HDRI_6-7.0.8.62-1.mga7.tainted.x86_64 lib64orcus0.14_0-0.14.1-2.mga7.x86_64 lib64startup-notification1_0-0.12-11.mga7.x86_64 are now orphaned, if you wish to remove them, you can use "urpme --auto-orphans" Gain : 204916 k
CC: (none) => chris
Created attachment 12482 [details] remove-old-kernels (script updated) I have improved the script in order to protect the kernel in use, even it is not the last. It is always protected. I hope it answers to some questions in the mailing list. The DEBUG mode (set DEBUG=1) is absolutely safe. I have tried to load old kernels in any order, it always works. This stupid game is reserved to advanced users.
CC: (none) => jarillon
CC: (none) => egc
*** Bug 29749 has been marked as a duplicate of this bug. ***
CC: (none) => joselpddj
@Pascal urpme --auto-orphans does not always remove all unused kernels. @Pierre: can we have a package for that script? And some timer, cron, systemd, trigger? ... and a configuration file, preferably /etc/sysconfig/kernels I just hate my /boot gets full with old kernels and I have to manually remove them. Specially I have setup laptops for my staff, they can update (install kernels), but cannot remove them. Then they call me, when /boot is full again... That is really annoying.
I totally agree with comment 4, can we make a package with this script that runs for example 1 time a month?? Or as suggestion, it could also be integrated in some way into mgaupdate, so that when the installation of updates by the user is finished, it will offer to uninstall old unused kernels in a graphical and transparent way?
btw. can this script manage devel kernels as well?
Created attachment 13031 [details] Remove old kernels with interactive modes New update. Version 0.95 Usage : remove-old-kernels -? The core function of the script is the same as attachment 10776 [details]. It differs only with parameters in command line, interactive, and usage. You can put it in a repository and make a package with this script. Feel free to modify and improve it. If you want a license, GPL is a good choice.
I am of the opinion that this bug should be closed as INVALID. 1) urpmi --auto-orphans removes already unused kernels 2) urpme thekerneliwanttoremove will exactly remove the kernel you want to remove. You're just calling for *troubles* by having a script automatically removing old kernels. Don't complain afterwards if your system is locked at boot and you need a rescue disk to start it You have been warned! cheers, chris.
CC: (none) => eatdirt
1- urpmi --auto-orphans does nothing, 2- urpme --auto-orphans works but don't remove old kernels. 3- All users are not able to use a command line as you. 4- The script keeps the number of old kernels you want. 5- last week I have found again ~30 kernels in a PC with all updates were done. 6- the script shows what can be done and demands before removing. 7- Please, try it!
(In reply to Pierre Jarillon from comment #36) > 1- urpmi --auto-orphans does nothing, > 2- urpme --auto-orphans works but don't remove old kernels. > 3- All users are not able to use a command line as you. > 4- The script keeps the number of old kernels you want. > 5- last week I have found again ~30 kernels in a PC with all updates were > done. > 6- the script shows what can be done and demands before removing. > 7- Please, try it! The 2nd is not entirely correct. urpme --auto-orpahns works but not under all circumstances If you have a clean fresh installation you can use urpme --auto-orphans and it will work. If you have your system upgrade from one to another major version, sometimes urpme --auto-orphans will not remove old kernels sometimes. If you have mixed kernels like desktop-kernels and server-kernels urpme --auto-orphans will not remove old kernels sometimes. I don't know why. B.t.w. on linux mint you can choose if you want to remove old kernels or not. And keep the latest 2 kernels, but this is only a desktop system. My way is to remover all old kernels except the running one and then update the new kernel. If this goes wrong i have always one running kernel.
Hi all, I have tried the script updated in a computer with Mageia 8 updated from Mageia 7 (Plasma Kde the two computers). The script works fine for me, have removed all old-kernels except the last two kernels installed. I think that we should create a rpm package for install by default in all desktop environments of Mageia, or integrate it with mgaupdate, for the script execute when the updates finish. My experience as packager don't good for this..... Greetings!
As of today, on my mageia 8 system: sudo urpme --auto-orphans writing /var/lib/rpm/installed-through-deps.list To satisfy dependencies, the following 53 packages will be removed (760MB): (orphan packages) kernel-linus-5.10.70-1.mga8-1-1.mga8.x86_64 kernel-linus-5.10.75-1.mga8-1-1.mga8.x86_64 kernel-linus-5.10.78-1.mga8-1-1.mga8.x86_64 kernel-linus-devel-5.10.70-1.mga8-1-1.mga8.x86_64 kernel-linus-devel-5.10.75-1.mga8-1-1.mga8.x86_64 kernel-linus-devel-5.10.78-1.mga8-1-1.mga8.x86_64 kernel-server-5.10.62-1.mga8-1-1.mga8.x86_64 kernel-server-5.10.70-1.mga8-1-1.mga8.x86_64 kernel-server-5.10.78-1.mga8-1-1.mga8.x86_64 kernel-server-devel-5.10.70-1.mga8-1-1.mga8.x86_64 kernel-server-devel-5.10.75-1.mga8-1-1.mga8.x86_64 kernel-server-devel-5.10.78-1.mga8-1-1.mga8.x86_64 lib64cap-devel-2.46-1.mga8.x86_64 lib64dbus-devel-1.13.18-3.mga8.x86_64 lib64double-conversion-devel-3.1.5-2.mga8.x86_64 lib64evdev-devel-1.11.0-1.mga8.x86_64 As you can see, it removes old kernels. Therefore, we should first understand why it works on some system, like mines, and why it does not work on others.
How would you tell urpme to keep two (or another specified number of) kernels? Besides, it removes *wrong* kernels: $ sudo urpme --test --auto-orphans ... kernel-desktop-5.15.4-1.mga8-1-1.mga8.x86_64 kernel-desktop-5.15.6-1.mga8-1-1.mga8.x86_64 kernel-desktop-devel-5.15.6-1.mga8-1-1.mga8.x86_64 virtualbox-kernel-5.15.4-desktop-1.mga8-6.1.30-1.mga8.x86_64 virtualbox-kernel-5.15.6-desktop-1.mga8-6.1.30-1.1.mga8.x86_64 $ rpm -qa | grep kernel | grep desktop virtualbox-kernel-5.10.78-desktop-1.mga8-6.1.28-1.4.mga8 virtualbox-kernel-5.15.4-desktop-1.mga8-6.1.30-1.mga8 kernel-desktop-5.15.4-1.mga8-1-1.mga8 kernel-desktop-5.15.6-1.mga8-1-1.mga8 kernel-desktop-devel-latest-5.15.6-2.mga8 kernel-desktop-5.10.78-1.mga8-1-1.mga8 kernel-desktop-devel-5.15.6-1.mga8-1-1.mga8 virtualbox-kernel-5.15.6-desktop-2.mga8-6.1.30-1.2.mga8 virtualbox-kernel-5.15.6-desktop-1.mga8-6.1.30-1.1.mga8 kernel-desktop-latest-5.15.6-2.mga8 kernel-desktop-5.15.6-2.mga8-1-1.mga8 kernel-desktop-devel-5.15.6-2.mga8-1-1.mga8 kernel-desktop-devel-5.15.4-1.mga8-1-1.mga8 kernel-desktop-devel-5.10.78-1.mga8-1-1.mga8 virtualbox-kernel-desktop-latest-6.1.30-1.2.mga8 ..hm could somehow it be because i for this test installed 5.10.78 and have not rebooted yet?
I think that --auto-orphans, don't works if Mageia 8 have updated from Mageia 7. For me, --auto-orphans works fine normally, but I check --auto-orphans often by terminal. A normal user, haven't the knowledge necessary for check this in terminal often, so, we should offer a way for this task is more simple for the normal user, and this don't fill their hard disk of old kernels with space unnecessary. This user can check the system whit a application for it, for example bleachbit or stacer, and he can cry when see that her hard disk is full of this old files rubish. Greetings!
(In reply to Morgan Leijström from comment #40) > How would you tell urpme to keep two (or another specified number of) > kernels? > > Besides, it removes *wrong* kernels: > > $ sudo urpme --test --auto-orphans > ... > kernel-desktop-5.15.4-1.mga8-1-1.mga8.x86_64 > kernel-desktop-5.15.6-1.mga8-1-1.mga8.x86_64 > kernel-desktop-devel-5.15.6-1.mga8-1-1.mga8.x86_64 > virtualbox-kernel-5.15.4-desktop-1.mga8-6.1.30-1.mga8.x86_64 > virtualbox-kernel-5.15.6-desktop-1.mga8-6.1.30-1.1.mga8.x86_64 Why do you think that ? Under normal circumstances, urpme --auto-orphans will remove all kernels except the current one. What is the output of uname -a to see which kernel are in use ? But sometimes something is special, i know
The important thing is to check if there is enough space before a kernel would be installed. If there was not enough space you will cry on the next reboot ;)
(In reply to Dieter Schütze from comment #42) > (In reply to Morgan Leijström from comment #40) > > Besides, it removes *wrong* kernels: ... > Under normal circumstances, urpme --auto-orphans will remove all kernels > except the current one. > What is the output of uname -a to see which kernel are in use ? Sorry i should have pointed that out: 5.15.6-desktop-2.mga8 was and is in use. (In reply to Dieter Schütze from comment #43) > The important thing is to check if there is enough space before a kernel > would be installed. If there was not enough space you will cry on the next > reboot ;) Been there... IIRC we have such bug open, too. It should check /boot and / before installing new kernels etc.
I have an idea for future releases of drakconf when regarding to remove old kernels. Why not add a box to tick somewhere that grants the system to automatically remove a certain number of kernels? Like, if you have more than 5 kernels installed and you're a normal user you tick a box to let the system remove unused kernels. I know that devs probably don't want this, but please feel free to develop my way of thinking to fit the normal user. This could be done in rpmdrake I suppose. A menu entry somewhere perhaps with an option to pre select? I guess I'm not making any sense, but it's worth a try.
In order to help progressing on this I pushed to cauldron a new package called urpme_old-kernels which will install Pierre's script renamed similarly (as I found it more in line with what we already have). I added a GPLv2+ license. Feel free Pierre to adapt as you want it, but do not publish SW without license please !! Hope it's useful at least for the people who asked for one pkg. We could always add an option to urpme for that but meanwhile that seems a useful temporary addition. See: http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20211214235655.bcornec.duvel.3580115.youri
Thanks very much. You did what I was not able to do. Now are the questions: - how and when use the script? - should virtualbox-kernel be included in the list ($LISTK)? - in line 80 perhaps we could add: [ ${NK} -le ${NBK} ] && exit 0
I think that this package should go to testing repos too.
(In reply to Bruno Cornec from comment #46) > In order to help progressing on this I pushed to cauldron a new package > called urpme_old-kernels which will install Pierre's script renamed > similarly (as I found it more in line with what we already have). > Why the pkg has an Epoch? :( We should avoid using it by any means possible. I would suggest to remove the pkg from mirrors and repush it without an Epoch.
CC: (none) => jani.valimaa
For fine-tuning think also we need to add the concept of kernel version series, and kernel flavours if we want to have it productive and meaningful on autoremoving, e.g. by adding something like: /etc/sysconfig/kernels_autoclean: KERNELS_KEEP=2 KERNEL_SERIES_KEEP=2 KERNEL_AUTO_CLEANUP=yes For instance we can have kernel-server kernel-desktop kernel-linus ... and so on. Which are three flavours. Then for each flavour, we might have some series: e.g. kernel-desktop-5.10.78 [to keep] kernel-desktop-5.15.6-1 [wipeable] kernel-desktop-5.15.6-3 [to keep] kernel-desktop-5.15.7-3 [to keep] etc. In the example above we might keep release 5.10.78 for some reason, e.g. because it builds some proprietary module of some software a user might have that maybe latest doesn't built yet), and for instance want to keep it, even if preserving the latest two.
CC: (none) => ghibomgx
It should remove any packages added by one of the kernel "latest" packages $ urpmq -y latest|grep -v perl kernel-desktop-devel-latest kernel-desktop-latest kernel-desktop586-devel-latest kernel-desktop586-latest kernel-linus-devel-latest kernel-linus-latest kernel-linus-source-latest kernel-server-devel-latest kernel-server-latest kernel-source-latest virtualbox-kernel-desktop-latest virtualbox-kernel-server-latest xtables-addons-kernel-desktop-latest xtables-addons-kernel-desktop586-latest xtables-addons-kernel-server-latest It should not remove the running kernel, or a kernel that is the last one for which the virtualbox or xtables kmod packages are available (the kmod updates do not get built for every kernel tested by qa, though they do for the kernels that get approved by qa).
(In reply to Chris Denice from comment #35) > I am of the opinion that this bug should be closed as INVALID. > You're just calling for *troubles* by having a script automatically removing > old kernels. Don't complain afterwards if your system is locked at boot and > you need a rescue disk to start it Not really, no. Other distros e.g. Fedora/RHEL or OpenSUSE have the configurable option to keep N number of kernels and to automatically remove older ones. Why can't we have that ? FWIW, here's a link for SUSE, where this is implemented in a sane and pretty configurable way: https://en.opensuse.org/SDB:Keep_multiple_kernel_versions#Enable_the_multiversion_kernel_feature
CC: (none) => doktor5000
Sorry for the Epoch field :-( (copied from another spec and miss that cleanup). SVN is updated. Will need sysadmin help for removal of old package. For people wwanting to contribute it's as easy as: svn co svn+ssh://svn.mageia.org/svn/packages/cauldron/urpme_old-kernels (for contributors) or provide a patch to https://svnweb.mageia.org/packages/cauldron/urpme_old-kernels/current/SOURCES/urpme_old-kernels?view=log so that it could be integrated.
>Not really, no. Other distros e.g. Fedora/RHEL or OpenSUSE have the configurable >option to keep N number of kernels and to automatically remove older ones. Why >can't we have that ? I tell by experience, not by saying others do it, let's do it. It also depends on how fast and how much kernel updates pop in, if you're rebooting your machine each time a new kernel update is installed etc...(note, we could also make a script for forcing a reboot after a kernel update...) Since you're all fancy having troubles, you must, at least, ensure that this script is not triggered by default, as some of you suggested, that's complete nonsense. It should have user approbation first. And, no one here seems to be concerned why urpme --auto-orphans works for some machines and not for others. I updated from mga7, so that is not the reason and I *never* had any problems with urpme --auto-orphans. I can see one possible reason, which would be that, somehow, you had performed a urpmi on an already installed package, like this: sudo urpmi kernel-server-5.15.6-2.mga8 Package kernel-server-5.15.6-2.mga8-1-1.mga8.x86_64 is already installed Marking kernel-server-5.15.6-2.mga8 as manually installed, it won't be auto-orphaned writing /var/lib/rpm/installed-through-deps.list Or maybe, one of the gui tool is buggy and is doing this automatically?
(In reply to Chris Denice from comment #54) > >Not really, no. Other distros e.g. Fedora/RHEL or OpenSUSE have the configurable >option to keep N number of kernels and to automatically remove older ones. Why >can't we have that ? > we could also make a script for forcing a reboot after a kernel update... Possibly put up a *reminder* to reboot each N hours if not rebooted since some important updates have been installed, but IMO that could as well be security fixes in browsers etc. Could be integrated in mgaapplet - feeel free to submit an enhancement request. I understand you are joking, but currently we are filling up some users /boot without asking, so boot may fail, that is worse ;) (OK it is actually another bug that install do not fully check for enough space, but it is getting worse from the fact we tell users we update (in common sense meaning replace), but actually *add*.) > at least, ensure that this > script is not triggered by default, as some of you suggested, that's > complete nonsense. It should have user approbation first. I agree only if users get noticed up front of the problem and easily get the choice in an easy way (by GIU, not editing a file). One idea: The mgaapplet have a configuration dialogue which have sliders for update frequency. Maybe add a slider for number of kernels to keep. Store that in a separate file that the script to remove kernels read. No file or number is zero -> do not run. File does by default not exist. If a kernel is installed by GUI tool and that file does not exist, pop up a message "When kernels are updated the old ones are by default kept. This will by time consume disk space." And a button [configure] that launch the dialogue I mentionned. Natural question: What about installations without mgaapplet? I would say that is only advanced users, and they can create that file and install the script if they want. > And, no one here seems to be concerned why urpme --auto-orphans works for > some machines and not for others. urpme --auto-orphans not working correctly sometimes is a separate fault - We should open a separate bug for this problem. Even if it worked as intended, it would not solve keeping n kernels (unless we add that functionality to it). And, we often recommend users to not use --auto-orphans, i.e https://wiki.mageia.org/en/Removing_packages#Answer: > I updated from mga7, so that is not the > reason and I *never* had any problems with urpme --auto-orphans. I can see > one possible reason, which would be that, somehow, you had performed a urpmi > on an already installed package ... > Or maybe, one of the gui tool is buggy and is doing this automatically? Regarding my test, I used only GUI tools (rpmdrake) for installing/"updating" kernels. I think we should handle the urpmi--auto-orphans quirks, and insufficient check for availiable space as other bugs. Uninstalling excess kernels is a separate enhancement even the fixes for them do not meet fully. (In reply to Pierre Jarillon from comment #47) > - should virtualbox-kernel be included in the list ($LISTK)? I dont think that is needed, in my test it uninstalled virtualbox-kernel wiith the kernel, so it seem to be handled by urpmi automatically. But that was just one test.
CC: (none) => epp
Happy New Year, friends! :) Unfortunately, I didn't understand some of the phrases that were written in this discussion, but I'll leave it here just in case... SnappyCleaner (see Releases): https://github.com/AKotov-dev/SnappyCleaner I dealt with the topic of old kernels more than 2 years ago. And... Old kernels need to be deleted by signature, which consists of all the numbers that are in the names of installed kernels. Thus, the resulting number of the newest core will be invariably greater than all the previous ones. I apologize if I have translated something badly again and this is not what we are talking about here... Once again, happy holidays to all! All the warmth, love and happiness in the New year 2022! :) Sincerely, Alex
CC: (none) => alex_q_2000
Very useful the script. I use it with the -a argument (automatic) It could be added in urpme package (as an executable) ? Afterall is up to the user to run it, if he wants (as the urpme --auto-orphans)
CC: (none) => dglent
Alex's application looks good :) But for now I tested Pierre's script from 10 December: https://bugs.mageia.org/attachment.cgi?id=13031 ___Some of the nice points: § Nice colour coded, green will be kept, red removed. § After listing it ask and can be run intractively, asking for each removal. § Removing kernel also removes virtualbox-kernel (urpmi do that itself, and also ask yes/no to that itself) § In automatic mode, urpmi do not ask that, good. ___Selection of packages could be improved To test downloading of packages i right before this test installed kernel-desktop-5.10.16-1. (without the -devel counterpart) This revealed that remove-old-kernels apparently go by install date, and do not correlate -devel packages to kernel. This is what i had left after running remove-old-kernels automatically: ==> kernel-desktop 1 : keep : kernel-desktop-5.10.16-1.mga8-1-1.mga8.x86_64 ons 19 jan 2022 20:44:08 2 : keep : kernel-desktop-5.15.15-1.mga8-1-1.mga8.x86_64 sön 16 jan 2022 18:19:57 used now ==> kernel-desktop-devel 1 : keep : kernel-desktop-devel-5.15.15-1.mga8-1-1.mga8.x86_64 sön 16 jan 2022 18:19:54 used now 2 : keep : kernel-desktop-devel-5.15.14-1.mga8-1-1.mga8.x86_64 ons 12 jan 2022 18:25:23 One idea to handle this is to not decide on -devel packages directly, but instead: 1) uninstall any kernel*-devel that do not have a corresponding kernel, and then 2) uninstall kernel*-devel packages for every kernel to uninstall. ( that said it is a user error to only install -devel with only some kernels, but this script is for normal users ;) ) __Probably not because of this script, but looks ugly: During removal of every virtualbox module, right before "depmod...." it displays lines like /usr/sbin/dkms: line 2006: echo: write error: Broken pipe /usr/sbin/dkms: line 1861: echo: write error: Broken pipe
I have found an improvement for my script. In order to exit quickly if there is no removable kernel, add at the end of Analyse /boot/ (line 81) [ $MODE = "A" ] && [ ${NK} -le ${NBK} ] && exit 0 In this case, the script has no need to scan all the kernel packages. This can be useful in automatic mode and NBK >2. Use my script or another, change the colors as you want, but please take a decision, I wish to never found more than 20 kernels in a machine of a user who made conscientiously all the updates and whose the root partition is full.
*** Bug 29943 has been marked as a duplicate of this bug. ***
CC: (none) => gouessej
Created attachment 13107 [details] Script to keep only the most recently installed kernel and the kernel currently in use
I agree with Pierre, please make a decision. Does anybody plan to fix the support of installonly_limit in DNF so that this existing setting is taken into account?
Add the package urpme_old-kernels (in urpmi dependencies) - Add an option in MCC to remove old kernels automatically, unchecked by default. - (or) Leave only the cli command available to the user, if he launches it, it means that he knows what he is doing.
(In reply to Julien Gouesse from comment #62) > I agree with Pierre, please make a decision. Does anybody plan to fix the > support of installonly_limit in DNF so that this existing setting is taken > into account? This should work in Cauldron / upcoming Mageia 9 as I have changed the way we name kernels, so dnf should now be able to detect the amount of installed kernels. But we wont do that for Mageia 8 as there is way too many bits that will break
@Thomas: is there a way to have this feature in urpm* too? or will I have to use dnf instead?
is it possible to create an automatic GRUB2 entry, such that should /boot/EFI (or /boot if used) becomes full, the user is able to restore DE access without too much effort? we already have "default" = Mageia "advanced" "recovery mode" add something like: "recovery mode" with sub heading "remove some older kernels", to automatically check if /boot/EFI (or /boot) is full. If so, then offer to run the script, request root user password, run the script, run "update-grub2" and then reboot. reasoning is: if the user is unaware that /boot (/boot/EFI ) is full, they may be unaware of the need to run the script. The package should be part of the original install, or a dependency of "kernel -***-latest, so that it is installed for use before the requirement to use it, user may not even be aware of the package name to download and or run if it is part of MCC GUI. just my 2 cents :)
CC: (none) => westel
It would need to be boot loader independent. I use refind on my uefi laptop.
@Dave: we don't have to develop a tool which works everywhere. Even having a tool which works in a common place would help. If we search or try to implement sth. that works everywhere, we will end up having nothing after years.
Created attachment 13236 [details] Pierre Jarillon script for removing old kernels Howdy. After following a discuss thread here: https://ml.mageia.org/l/arc/dev/2021-12/msg00058.html I've been using the attached script w/o any problem on two PC desktops and two thin client desktops, all running up-to-date Plasma. It appears to differ slightly from a newer, untested by me version here: http://www.jarillon.org/remove-old-kernels $ diff `which remove-old-kernels-jarillon` remove-old-kernels 80c80 < [ ${NK} -le ${NBK} ] && exit 0 --- > [ $MODE = "A" ] && [ ${NK} -le ${NBK} ] && exit 0 FWIW. Seems to be a good candidate for distro inclusion, IMO. Thanks.
CC: (none) => rolfpedersen
I had intended to indicate I've used the script regularly since last December 10.
The difference is: - before, if no candidate to be deleted => exit without any explanation. - after, this occurs only in automatic mode. This allows to use the script faster when there is nothing to delete.
This is working very fine for me in all computers that I have tried it. Although a normal user should have a graphical interface or at least have this script translated into the system language, and this tool should be run when new updates are installed to check for obsolete kernels. I guess this will be the goal for Mageia 9. Greetings!!
Add to MCC a checkbox: - Automatically remove old kernels À spinbox : - Number of kernels to keep
*** Bug 9258 has been marked as a duplicate of this bug. ***
CC: (none) => pmithrandir
CC: (none) => johnltw
CC: (none) => saveurlinux
will we have this implemented in mga9??
(In reply to Marc Krämer from comment #75) > will we have this implemented in mga9?? I hope so. As previously happened in #14 my brother-in-law again was on the 'phone today as his (now not Mageia 6 but Mageia 8) machine again was failing to update with insufficient disc space on the root partition. I spent an hour or so talking him through kernel removal keypress by keypress! It's no joke! 32 old kernels were removed using one of the scripts that he first had to wget from my server, again one key press at a time. urpme --auto-orphans removed another 1.2GB of orphan packages. He now has 6.5GB free space which is plenty for his use. This MUST be automated before Mga 9 for non-tech users, nerds can disable as they wish, but a system that breaks itself automatically is just crazy!
However the most recent script attached here does absolutely nothing in Cauldron. ...and neither does the one I used earlier today with the remote Mageia 8, so these will need updating for Mageia 9. (Both from Pierre Jarillon) n=0 always, with 40 kernels in /boot/ :(
(In reply to Barry Jackson from comment #77) > However the most recent script attached here does absolutely nothing in > Cauldron. > > ...and neither does the one I used earlier today with the remote Mageia 8, > so these will need updating for Mageia 9. (Both from Pierre Jarillon) > > n=0 always, with 40 kernels in /boot/ :( Mine still works on Mageia 8: https://bugs.mageia.org/attachment.cgi?id=13107
(In reply to Julien Gouesse from comment #78) > Mine still works on Mageia 8: > https://bugs.mageia.org/attachment.cgi?id=13107 Yes Mga8 is fine, the problem is only cauldron. It seems to be a bug/change in the way rpm -qa --last handles parameters. I have forwarded some debug info and a possible partial fix to Pierre directly.
Created attachment 13403 [details] Possible patch for remove-old-kernels-jarillon for Mga9 This patch seems to work OK in Cauldron in a simple system.
...and also OK for me in Mageia 8 There is one small issue that I came across in testing. If there are orphans on the system, then in what should be non-interactive mode, the script pauses after each kernel removal with the orphans message and it becomes interactive. (@Pierre note: interactive not interactif in English :) Similarly if other dependant packages are involved, even with -a To satisfy dependencies, the following 2 packages will be removed (73MB): kernel-desktop-5.10.20-2.mga8-1-1.mga8.x86_64 virtualbox-kernel-5.10.20-desktop-2.mga8-6.1.18-18.mga8.x86_64 (due to missing kernel-desktop-5.10.20-2.mga8, due to missing kernel-desktop-5.10.20-2.mga8[*]) Remove 2 packages? (y/N)
Ignore the 'small issue' in comment 81 - I had not noticed that the interactive "I" flag was set in the default config in the script. With that set to "A" the script is truly non-interactive so ideal for running from a cron job or in the background. With the patch it is now working fine in both Mga8 and 9. Thanks Pierre, cleaning up all my systems now :)
@bcornec I have committed the above small changes to urpme_old-kernels in svn which fix it for Mga9. Also stopped it from requiring e.g. grub2 when only grub2-efi is actually needed in an efi system. We have a virtual provide in both grub2 packages for this.
Hi all, How will this be implemented in Mageia9 finally? I don't see nothing in cauldron still. Greetings!
https://madb.mageia.org/package/show/application/0/release/cauldron/name/urpme_old-kernels
(In reply to sturmvogel from comment #85) > https://madb.mageia.org/package/show/application/0/release/cauldron/name/ > urpme_old-kernels That is not enough. It needs to be automatic and default for users who have no clue how to run a script. Expert users can configure or disable as they wish. See comments 14 and 76.
True - urpme_old-kernels is not a sufficient solution.
I know you've already covered this a lot, but maybe there's no need to reinvent the wheel. Manjaro has a nice little gui and also has a command line thing for kernels. It's not automatic, but it's a good option. https://linuxhint.com/change-kernel-version-manjaro/ Maybe it's worth a read. Regards: Csaba
(In reply to Barry Jackson from comment #86) > (In reply to sturmvogel from comment #85) > > https://madb.mageia.org/package/show/application/0/release/cauldron/name/ > > urpme_old-kernels > > That is not enough. > > It needs to be automatic and default for users who have no clue how to run a > script. > > Expert users can configure or disable as they wish. > > See comments 14 and 76. change to dnf there are only 3 kernels to keep in the default config. You can adjust this in the dnf.conf with installonly_limit=x where x is a number from 0 (ulimitted) to what you want to keep. attention the number 1 is not allowed, to advoid kernel install issues Regards: Dieter
(In reply to Dieter Schütze from comment #89) > (In reply to Barry Jackson from comment #86) > > (In reply to sturmvogel from comment #85) > > > https://madb.mageia.org/package/show/application/0/release/cauldron/name/ > > > urpme_old-kernels > > > > That is not enough. > > > > It needs to be automatic and default for users who have no clue how to run a > > script. > > > > Expert users can configure or disable as they wish. > > > > See comments 14 and 76. > > change to dnf there are only 3 kernels to keep in the default config. > You can adjust this in the dnf.conf with installonly_limit=x where x is a > number from 0 (ulimitted) to what you want to keep. > attention the number 1 is not allowed, to advoid kernel install issues > > Regards: Dieter Have you ever tested it with Mageia 9? The last time I gave it a try in Mageia 8, I didn't get the expected behaviour: [root@localhost gouessej]# dnf remove --oldinstallonly --setopt installonly_limit=2 kernel Erreur : Aucun ancien paquet « installonly » n’a été trouvé pour suppression. which means Error: No old package « installonly » has been found for removal.
(In reply to Julien Gouesse from comment #90) > (In reply to Dieter Schütze from comment #89) > > (In reply to Barry Jackson from comment #86) > > > (In reply to sturmvogel from comment #85) > > > > https://madb.mageia.org/package/show/application/0/release/cauldron/name/ > > > > urpme_old-kernels > > > > > > That is not enough. > > > > > > It needs to be automatic and default for users who have no clue how to run a > > > script. > > > > > > Expert users can configure or disable as they wish. > > > > > > See comments 14 and 76. > > > > change to dnf there are only 3 kernels to keep in the default config. > > You can adjust this in the dnf.conf with installonly_limit=x where x is a > > number from 0 (ulimitted) to what you want to keep. > > attention the number 1 is not allowed, to advoid kernel install issues > > > > Regards: Dieter > > Have you ever tested it with Mageia 9? The last time I gave it a try in > Mageia 8, I didn't get the expected behaviour: > [root@localhost gouessej]# dnf remove --oldinstallonly --setopt > installonly_limit=2 kernel > Erreur : Aucun ancien paquet « installonly » n’a été trouvé pour suppression. > which means > Error: No old package « installonly » has been found for removal. I think this is the wrong place to discuss that But for me it worked with mageia 9 but i use only dnf and follow the warning of the mageia description to use dnf. https://wiki.mageia.org/en/Using_DNF#Warning_about_orphans_mechanisms I haven't tested it with many old kernels because since dnf there aren't any old kernels installed anymore. They were automatically removed when installing a new kernel. Have you tested this with a new kernel and the installonly_limit parameter in the dnf.conf ? Or only direct in the shell with the remove option ?
(In reply to Dieter Schütze from comment #89) > (In reply to Barry Jackson from comment #86) > > change to dnf there are only 3 kernels to keep in the default config. > You can adjust this in the dnf.conf with installonly_limit=x where x is a > number from 0 (ulimitted) to what you want to keep. > attention the number 1 is not allowed, to advoid kernel install issues > > Regards: Dieter No, I'm sorry but this is Mageia not Fedora. I do not use dnf and neither will new users who make a default install. I do have dnf installed but only to use mock, but what I do is not relevant. This is NOT about experts, but about a default Mageia installation breaking itself during its life-cycle for regular users. Maybe remove_old-kernels could be used by the kernel package to run after update-grub2? remove_old-kernels could be easily modified to source a config file in /etc where it could be disabled or adjusted as required. Regular users would get the default behaviour and anyone wanting something different would surely have the ability to edit a config file. I see this as the simplest solution capable of satisfying everyone. WE MUST DO SOMETHING! Regards, Barry
@Barry: full credit from my perspective too.
(In reply to Dieter Schütze from comment #91) > (In reply to Julien Gouesse from comment #90) > > (In reply to Dieter Schütze from comment #89) > > > (In reply to Barry Jackson from comment #86) > > > > (In reply to sturmvogel from comment #85) > > > > > https://madb.mageia.org/package/show/application/0/release/cauldron/name/ > > > > > urpme_old-kernels > > > > > > > > That is not enough. > > > > > > > > It needs to be automatic and default for users who have no clue how to run a > > > > script. > > > > > > > > Expert users can configure or disable as they wish. > > > > > > > > See comments 14 and 76. > > > > > > change to dnf there are only 3 kernels to keep in the default config. > > > You can adjust this in the dnf.conf with installonly_limit=x where x is a > > > number from 0 (ulimitted) to what you want to keep. > > > attention the number 1 is not allowed, to advoid kernel install issues > > > > > > Regards: Dieter > > > > Have you ever tested it with Mageia 9? The last time I gave it a try in > > Mageia 8, I didn't get the expected behaviour: > > [root@localhost gouessej]# dnf remove --oldinstallonly --setopt > > installonly_limit=2 kernel > > Erreur : Aucun ancien paquet « installonly » n’a été trouvé pour suppression. > > which means > > Error: No old package « installonly » has been found for removal. > > I think this is the wrong place to discuss that > But for me it worked with mageia 9 but i use only dnf and follow the warning > of the mageia description to use dnf. > https://wiki.mageia.org/en/Using_DNF#Warning_about_orphans_mechanisms > > I haven't tested it with many old kernels because since dnf there aren't any > old kernels installed anymore. They were automatically removed when > installing a new kernel. > Have you tested this with a new kernel and the installonly_limit parameter > in the dnf.conf ? > Or only direct in the shell with the remove option ? I tested both but only with Mageia 8. As it works with Mageia 9, it's a good piece of news for those using DNF. However, I agree with Barry, a simple solution must be found to clean this mess for many users who don't even know what DNF is. Many newbies create a single partition and end up driving Mageia impossible to run. Either Mageia >= 9 should use DNF by default if and only if it is reliable enough or a fix requiring no intervention should be provided. Fedora supports several package managers including both RPM and DNF, does it have the same problem with old kernels when not using DNF? RPM seems to be the default package manager in Fedora too: https://docs.fedoraproject.org/en-US/quick-docs/package-management/ "Fedora is a distribution that uses a package management system. This system is based on rpm , the RPM Package Manager".
@tmb Thomas, is there a chance that you could add a call to /usr/bin/remove_old-kernels after the current call to grub2-mkconfig, in kernel packages such that it is simply ignored if the script is not found? See comment 92 This would allow us to do some live script testing and move forward with this issue in time for Mga9. Thanks, Barry
CC: (none) => tmb
@tnb Actually we would need: /usr/bin/urpme_old-kernels -a or even: /usr/bin/urpme_old-kernels -a >> /var/log/urpme_old-kernels.log ...although the colour control characters look a bit odd in the log. I have modified (locally) urpme_old-kernels to use a config file to control the number of kernels to keep and the kernel types to check for, so that systems without special kernels can exclude unneeded ones to speed the process. The config file settings override any other settings if the file exists. I can commit these changes if you feel it's a possible way to go. Barry
I just realized the flaw is the above. This would need to run AFTER a kernel install but BEFORE grub2-mkconfig. This reminds me of the other chicken and egg situation involving grub2-mkconfig we had some years back!
OK I have decided to go ahead with this using cron/anacron so as not to involve kernel packaging at all. I have created a new package, 'remove-old-kernels' based on the remove-old-kernels-jarillon script and urpme_old-kernels with some modifications. I did not like the package name 'urpme_old-kernels', as it is not descriptive for new users, and it has mixed underscore and hyphen, so confusing. remove-old-kernels creates a monthly cron job on installation without user intervention, so that including the package (about 8kB) in the installer would be all that is required. It has a config file where the 'number of kernels to keep' can be set (default is 4 ??), and also the types of kernel to include for removal (default is all). Any dependant packages like related vbox kernels are also removed by urpme. It logs output to /var/log/remove-old-kernels.log It may be run interactively using the command line switches as per the original stand-alone script if required. I have it installed on 3 machines set up with cron daily to speed live testing and will commit it if all goes well. I could see this issue going on for another year or more if something was not done, so am hoping that this will be suitable for everyone. It can be easily un-installed so nobody will be forced to use it, however machines should not self destruct with it installed. Barry
@Barry: good news. Is it already in cauldron? I suggest having less than 4 kernels per default. Regular users only need the current running kernel and maybe 1 old kernel. cron.daily is a good place - keep it there. Are devel-packages (needed by dkms) removed too?
(In reply to Marc Krämer from comment #99) > @Barry: good news. Is it already in cauldron? Not yet but it can be later today. > I suggest having less than 4 kernels per default. Regular users only need > the current running kernel and maybe 1 old kernel. Initially I was thinking of keeping more, so testers have a few to remove, however you are right, since once installed the config file is not updated so I will change that in the package. I would recommend that the number is increased for testing or after one run there will be nothing left to remove! > cron.daily is a good place - keep it there. Since we rarely have more than one or two kernel updates in a month (guess) I was going to use cron.monthly. Why daily? Maybe compromise on weekly? > > Are devel-packages (needed by dkms) removed too? Anything that 'Requires' a kernel being removed is removed by urpme. It initially will not obsolete urpme_old-kernels, but I think it should do later since remove-old-kernels can be used interactively as well and does the same job when used that way.
OK, 'remove-old-kernels' submitted to cauldron. Should hit the mirrors later today. Please test as much as possible. Note the README.urpmi pop-up during installation. To test daily, you can move /etc/cron.weekly/remove-old-kernels.cron into /etc/cron.daily/
(In reply to Barry Jackson from comment #100) > (In reply to Marc Krämer from comment #99) > > Are devel-packages (needed by dkms) removed too? > > Anything that 'Requires' a kernel being removed is removed by urpme. Which means the kernel-devel wont be removed as they intentionally does not require their matching kernel... Also you need to ensure this script does not run at all on systems that use dnf as that has it's own way of managing amount of installed kernels...
(In reply to Thomas Backlund from comment #102) > (In reply to Barry Jackson from comment #100) > > (In reply to Marc Krämer from comment #99) > > > > Are devel-packages (needed by dkms) removed too? > > > > Anything that 'Requires' a kernel being removed is removed by urpme. > > > Which means the kernel-devel wont be removed as they intentionally does not > require their matching kernel... > > > Also you need to ensure this script does not run at all on systems that use > dnf as that has it's own way of managing amount of installed kernels... 1. you don't have to install this package 2. if you do so, and it removes kernels dnf would not have, you may end up with less kernels, but this is what was configured.
(In reply to Marc Krämer from comment #103) > (In reply to Thomas Backlund from comment #102) > > (In reply to Barry Jackson from comment #100) > > > (In reply to Marc Krämer from comment #99) > > > > > > Are devel-packages (needed by dkms) removed too? > > > > > > Anything that 'Requires' a kernel being removed is removed by urpme. > > > > > > Which means the kernel-devel wont be removed as they intentionally does not > > require their matching kernel... > > > > > > Also you need to ensure this script does not run at all on systems that use > > dnf as that has it's own way of managing amount of installed kernels... > > 1. you don't have to install this package In comment 98 barjac suggested it be part of default install... wich means every one would get it regardless of needing/wanting it... but of course thats easy to fix... dont install it by default... > 2. if you do so, and it removes kernels dnf would not have, you may end up > with less kernels, but this is what was configured. No. dnf has its own config about how many kernels should be retained, so this script overriding that is not ok
Is dnf installed by default?
"dnf has its own config about how many kernels should be retained, so this script overriding that is not ok" I don't agree. If you install a package which is specially resposible to remove kernels, it can and should override this config. If you disable it with the installation of dnf, this is toally useless. I need dnf for external applications (e.g. vivaldi). So dnf is just used to update these packages. Everything else is handled by mga tools.
(In reply to Barry Jackson from comment #105) > Is dnf installed by default? yes, ever since we decided to support it in Mageia. it's also needed for any use of gnome-software, plasma discover, flatpak, ... I guess one way to cope with this would be check if this file is present: /etc/dnf/dnf.conf and if it is, check the line: installonly_limit=3 and if that number is bigger than what your script config has set, obey dnf conf, otherwise obey the script config
(In reply to Marc Krämer from comment #106) > "dnf has its own config about how many kernels should be retained, so this > script overriding that is not ok" > I don't agree. If you install a package which is specially resposible to > remove kernels, it can and should override this config. > Well, you still missed the point, if Mageia default install adds that package, the enduser has not decided to "If you install a package..." > If you disable it with the installation of dnf, this is toally useless. I > need dnf for external applications (e.g. vivaldi). So dnf is just used to > update these packages. Everything else is handled by mga tools. That's _your_ usercase... We also support people using _only_ dnf. I dont object to this tool as such, it just need to be implemented properly.
(In reply to Thomas Backlund from comment #108) > (In reply to Marc Krämer from comment #106) > > "dnf has its own config about how many kernels should be retained, so this > > script overriding that is not ok" > > I don't agree. If you install a package which is specially resposible to > > remove kernels, it can and should override this config. > > > > Well, you still missed the point, if Mageia default install adds that > package, the enduser has not decided to "If you install a package..." Did we ever say this package is installed by default? Where? But if we do, I'm glad. > > If you disable it with the installation of dnf, this is toally useless. I > > need dnf for external applications (e.g. vivaldi). So dnf is just used to > > update these packages. Everything else is handled by mga tools. > > That's _your_ usercase... > We also support people using _only_ dnf. I'm fine with that too. Just respect this as a valid user case as well. > I dont object to this tool as such, it just need to be implemented properly.
(In reply to Marc Krämer from comment #109) > > Did we ever say this package is installed by default? Where? > But if we do, I'm glad. > Barjac suggested it in comment 98: <quote> remove-old-kernels creates a monthly cron job on installation without user intervention, so that including the package (about 8kB) in the installer would be all that is required. </quote> And yes, I think it should be added by default as long as we get it done properly. > > > If you disable it with the installation of dnf, this is toally useless. I > > > need dnf for external applications (e.g. vivaldi). So dnf is just used to > > > update these packages. Everything else is handled by mga tools. > > > > That's _your_ usercase... > > We also support people using _only_ dnf. > I'm fine with that too. Just respect this as a valid user case as well. > Apparently we are "arguing" about something we actually are in agreement on... I'm trying to make that same point ... protecting the endusers choice of package manager and how they use it/them and try to not cause any unexpected behaviour if we can avoid it...
(In reply to Thomas Backlund from comment #107) > (In reply to Barry Jackson from comment #105) > > Is dnf installed by default? > > yes, ever since we decided to support it in Mageia. > > it's also needed for any use of gnome-software, plasma discover, flatpak, ... > > I guess one way to cope with this would be check if this file is present: > /etc/dnf/dnf.conf > > and if it is, check the line: > > installonly_limit=3 > > and if that number is bigger than what your script config has set, obey dnf > conf, otherwise obey the script config OK that seems reasonable, I will look at it over the weekend. I had to laugh at: "which means every one would get it regardless of needing/wanting it..." Just like dnf! /o\
(In reply to Barry Jackson from comment #111) > (In reply to Thomas Backlund from comment #107) > > (In reply to Barry Jackson from comment #105) > > > Is dnf installed by default? > > > > yes, ever since we decided to support it in Mageia. > > > > it's also needed for any use of gnome-software, plasma discover, flatpak, ... > > > > I guess one way to cope with this would be check if this file is present: > > /etc/dnf/dnf.conf > > > > and if it is, check the line: > > > > installonly_limit=3 > > > > and if that number is bigger than what your script config has set, obey dnf > > conf, otherwise obey the script config > > OK that seems reasonable, I will look at it over the weekend. > > I had to laugh at: > "which means every one would get it regardless of needing/wanting it..." > > Just like dnf! /o\ Yep :) I dont use dnf either on my mageia systems, but I know several endusers are using it explicitly so we need to cope with their needs/expectations too.. but that's why we install it by meta-task rpmsrate, not as a hard dep so powerusers still can remove it (and the same will be done for this script to if agreed on that it shuldo be part of default install) if they choose to do so...
CC: jani.valimaa => (none)
Please update to remove-old-kernels-0.98-2 for testing. Changes: Quite a major bug related to kernel selection fixed. Kernels are now not sorted by install date, but by version number. Kernels to keep limit will now be no lower than that set by dnf. (only if installed) the default for that is 3 the same as ours.
(In reply to Barry Jackson from comment #113) > Please update to remove-old-kernels-0.98-2 for testing. > Changes: > Quite a major bug related to kernel selection fixed. > Kernels are now not sorted by install date, but by version number. I'm not sure that's a good idea. It should follow install date, as if there are older kernels installed after the "newest one /biggest version" on the system, the enduser has most likely opted for that him/herself to work around bugs in newer kernels...
And I assume the script wont ever try to remove the running kernel, or ?
(In reply to Thomas Backlund from comment #114) > I'm not sure that's a good idea. > > It should follow install date, as if there are older kernels installed after > the "newest one /biggest version" on the system, the enduser has most likely > opted for that him/herself to work around bugs in newer kernels... OK point taken, I randomly installed various kernels for testing and it looked like a bug, however I had not considered that use case. I will revert that change. (In reply to Thomas Backlund from comment #115) > And I assume the script wont ever try to remove the running kernel, or ? No ;) At present it keeps all flavours with the same version-release as the running kernel, and marks them all as 'in use'. Probably because finding the full package name of the running kernel is not easy.
(In reply to Barry Jackson from comment #116) > (In reply to Thomas Backlund from comment #115) > > And I assume the script wont ever try to remove the running kernel, or ? > > No ;) > > At present it keeps all flavours with the same version-release as the > running kernel, and marks them all as 'in use'. Probably because finding the > full package name of the running kernel is not easy. $ uname -r 6.0.3-desktop-1.mga9 $ rpm -qf /lib/modules/6.0.3-desktop-1.mga9 kernel-desktop-6.0.3-1.mga9 or simply: $ rpm -qf /lib/modules/$(uname -r)
Excellent that fixes another issue :) Thanks! #### Please update to remove-old-kernels-0.98-3 for testing. #### Changes: Kernel sort order reverted to date installed not version. Only the actual kernel is use is marked as "in use" and un-removable, rather than all kernels with the same version as previously.
(In reply to Barry Jackson from comment #116) > (In reply to Thomas Backlund from comment #115) > > And I assume the script wont ever try to remove the running kernel, or ? > drakrpm DOES ...without complaint! I discovered this yesterday while testing. With an assortment of kernels installed in cauldron, I booted into a kernel-linus. I continued doing some work and at the end decided to remove all the extra kernels and just leave the desktop flavour installed, forgetting that I was running the kernel-linus. All were un-installed without complaint by drakrpm! The system continued to run with uname -r still showing the now removed kernel version. All mention of the current kernel had gone from /boot. This of course broke the script which initially drew my attention to what had happened. I have since repeated this in Mageia 8. Have we a serious bug in drakrpm?
Since the above behaviour is not currently unexpected I will stop remove-old-kernels from removing anything at all if the currently running kernel package has been removed. https://bugs.mageia.org/show_bug.cgi?id=31015 In this situation it cannot decide which of the remaining kernels to keep until after a re-boot, or until the running kernel package has been re-installed. It's a rare corner case but better to be safe.
but isn't it a bug of urpme to remove the current running kernel? I'd say this is a blocker bug.
Recently on the French forum, what looked like a sophisticated and thorough script was offered which would resolve this request bug if we can adopt it. I will try to find it. Re bug 31015, we must be careful NOT to remove the running kernel!
CC: (none) => lewyssmithSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=31015
I have tried remove-old-kernels-0.98-3 and read carefully the script. I have made tests on 2 PC, one with 3 and the other with 6 desktop kernels and 6 desktop-devel kernels. I have also booted on an old kernel which have been protected. === Better information My last change in #c59 ( Comment 59 ) is not included line 93 replace [ ${NK} -le ${NBK} ] && exit 0 with [ $MODE = "A" ] && [ ${NK} -le ${NBK} ] && exit 0 this allows in interactive mode to see which kernels are installed and which kernel is in use. === Priority to interactive mode It should be better to have # Source config file before #Parsing arguments This allows to use NBK different from NBK of /etc file This allows -a -d -n2 even if NBK=3 in /etc file. === Other @Barry Jackson : Please add your name as author of the script! You did a great job! Thanks.
@ Pierre I only just saw the last two comments, as I have been busy working on the next update after testing in several systems. Thanks for your testing. I will look at your suggestions above, but too late for this release. I have just pushed 0.98-4 which now has a desktop file, so it appears in the main menus (with icon :). Auth is provided by pkexec for the desktop file and now works OK in LXQT and plasma5 (more testing needed in other DEs). To speed the the loops it now runs rpm -qa --last only once before the looping which makes quite an improvement. It would be good if you could test the latest - thanks. @Lewis :) I also added a check for the running kernel being installed. This check aborts with a fatal before any removals can start.
Gosh, what a flurry of activity. My comment 122 was fatuous, without reading everything before. Sorry. Having perused all recent debate, my penny's worth: 1) Install 'remove-old-kernels' always, since the problem of accumulating kernels is universal. Clued-up users who do not want it can uninstall it. Mr Average User will benefit. 2) Certainly cater for DNF users. Simply ignore them (do nothing) *if* one can deduce that DNF is what they *routinely* use? Comment 102, comment 106. 3) I think 3 is a sensible default number to keep. 4) Agree about using kernel install date as the criterium. 5) For running it automatically, monthly as originally proposed was sensible, but I think there was justification for more often, so weekly looks OK. 6) There was much talk of Grub. I suppose if you remove kernels, you have to update it so as not to offer ones that no longer exist! BUT 7) Are Grub-less systems (rEFInd) considered? (Comment 67). This is generally the best option for EFI boxes, so should be almost the norm.
New version remove-old-kernels-0.99-1 pushed to cauldron. Changes: Don't leave terminal instantly when there is nothing to remove in interactive mode, added "Hit any key to exit". Don't waste time in auto mode if there are less than NBK in boot - Thanks Pierre! I seem to have issues with the icon showing as a black bar until after a reboot in plasma 'sometimes' - anyone else? Maybe my svg icon? @ Pierre - the cfg file is ONLY read in auto mode, so what you suggest is how it works now :) Please keep testing everyone, so we can maybe get this accepted. Barry
@Barry : I like your remove-old-kernels-0.99-1 The cfg file is ONLY read in auto mode: this is a good choice, even it is not mine ;-) Perhaps a little problem: the kernel list can be different in interactive and automatic mode. This can be confusing. A note in README.urpmi? or/and a comment in remove-old-kernels.cfg ? The icon is very nice. I like it! The mode of /usr/share/icons/hicolor/scalable/apps/remove-old-kernels.svg is 755 instead of 644 like other icons. Same problem with the .cfg file. The icon doesn't appear in the plasma menu, but only in Recent Applications. However, it appears when I want to edit the menu... I did all my tests with mageia8 on two desktops and my laptop. The parameter -n2 is replaced by 3. But 4, 5 ,6 work fine. This is not the case with the previous release.
(In reply to Pierre Jarillon from comment #127) > @Barry : I like your remove-old-kernels-0.99-1 > > The cfg file is ONLY read in auto mode: this is a good choice, even it is > not mine ;-) Perhaps a little problem: the kernel list can be different in > interactive and automatic mode. This can be confusing. A note in > README.urpmi? or/and a comment in remove-old-kernels.cfg ? The reasoning there is that specific flavours can be omitted from the config by expert users who may only want to automatically remove e.g.the regular desktop kernels. Non-tech users get the full list by default in both modes. > > The icon is very nice. I like it! Good! > The mode of /usr/share/icons/hicolor/scalable/apps/remove-old-kernels.svg is > 755 instead of 644 like other icons. Same problem with the .cfg file. Thanks for catching that! > The icon doesn't appear in the plasma menu, but only in Recent Applications. No, in Mga8 it 'sometimes' does not, but it does in cauldron - I have no idea why. If the menu entry (with invisible icon) is added to the panel then the icon does appear on the panel.. Here, now, on my Mga8 laptop the icon is on the panel and in the menu. > However, it appears when I want to edit the menu... Exactly! Weird. sometimes a re-boot has fixed this, probably a plasma caching thing. It seems fine in LXQT. > I did all my tests with mageia8 on two desktops and my laptop. > > The parameter -n2 is replaced by 3. But 4, 5 ,6 work fine. This is not the > case with the previous release. Is dnf installed? If so dnf default limit is 3 which over-rides remove-old-kernels. ...but I will check that there is nothing else happening. Thanks for testing :)
(In reply to Pierre Jarillon from comment #127) > The parameter -n2 is replaced by 3. But 4, 5 ,6 work fine. This is not the > case with the previous release. I can confirm that with dnf limit dropped to 2 in /etc/dnf/dnf.conf, then remove-old-kernels will respond correctly to -n2.
New version with clearer, improved texts everywhere. File permissions fixed. Coming to a mirror near you :) remove-old-kernels-0.99.1-1
remove-old-kernels-0.99.1-2.mga9 Just tried it on my Cauldron system: impeccable. All the ifs & buts seem to be there, all the precautions. Well done. I had 8 desktop kernels, it clearly showed the one in use, the three to keep, the 5 to remove - which it did. The man page is good too. Not a stone unturned. You will hate me for this micro comment!: - The colouration (as for all commands which use it) is unhelpful for white-on-black terminals. But leave as-is, don't change a good thing. It did not matter here. [I would love to see this stamped out: I often have to | cat or | less commands just to see the coloured output. No doubt you can configure your way out of this... I do not want to have to]. I suggest raising an enhancement bug for MCC to include this important tool, which I guess would be easy: just a launch icon. Either in 'Software Management' or 'System-Administrative Tools'. I prefer the former as being more evident to Mr Average User; the latter seems more precisely relevant. Perhaps in both places? What do others think?
Keywords: (none) => FOR_RELEASENOTES9
Hi Lewis, Thanks for your comments. Pierre and I are still working on this behind the scenes and have added some more 'ease of use' features, while keeping it simple. I think it is an improvement. The latest version will appear later this week, which will include the ability to turn off the automatic weekly cron jobs with a simple command line option for those who would like the tool but not the automatic part. I'm puzzled by your colour comment - do you mean white on black or black on white? I am attaching a screen shot of my current WIP version.
Created attachment 13467 [details] Screen shot using standard white on black terminal (konsole)
I said not to bother! Your example shows the green well enough, but the red *is* more obscure. Perhaps dark blue is worst (not your case), I have just tried 3 other commands with illegible blue fields. No point in attaching. > do you mean white on black or black on white? I did say white on black; a white screen shows all colours fine.
(In reply to Lewis Smith from comment #134) > I said not to bother! Yes I know ;) I find the screen really readable on both machines I use so I was just curious. I do change the font in my terminals to 14pt (old eyes here!). > > > do you mean white on black or black on white? > I did say white on black; a white screen shows all colours fine. I thought maybe it was a typo as I had never tried black on white so did not know how it would look. New version remove-old-kernels-0.99.1-3.mga9 is on BS now. @Lewis Item 2 is for you :) Changes:- - set kernels to keep and auto mode ON/OFF from command line - set no-colour output with cli option - show kernels to keep and auto mode on status line - warn when dnf setting is over-riding config setting - tidy script indentation - update man file - use full path to icon in desktop file or it fails to show in some DEs - fix -p option Please test and report any issues, Barry
Running from menu (Xfce): the icon is there. No kernels to remove, so nothing to add. > I suggest raising an enhancement bug for MCC to include this important tool > @Lewis Item 2 is for you I guess these these are related. Will do, but was hoping for some feedback on the idea. Am closing this bug, which does not prevent additional comments.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
(In reply to Lewis Smith from comment #136) > > I suggest raising an enhancement bug for MCC to include this important tool > > @Lewis Item 2 is for you (comment 131) > I guess these these are related. Will do, but was hoping for some feedback > on the idea. As I was raising the enhancement request (abandoned), I realised that it was superfluous because of the *automatic* nature of this tool. I was concerned about Mr Average User being easily aware of it to run it, but that is quite unnecessary. The more so as it is in the application menus for conscious on-demand use.
Hello, I think it should be kept open for release notes.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
(In reply to Lewis Smith from comment #137) > (In reply to Lewis Smith from comment #136) > As I was raising the enhancement request (abandoned), I realised that it was > superfluous because of the *automatic* nature of this tool. I was concerned > about Mr Average User being easily aware of it to run it, but that is quite > unnecessary. The more so as it is in the application menus for conscious > on-demand use. I agree, as long as it is included in rpmsrate. Anyone upgrading from a previous release will not get it, so certainly needs to be mentioned in release notes. I think, subject to any reports to the contrary, it is now ready.
(In reply to papoteur from comment #138) > I think it should be kept open for release notes. Do not see why; but if it needs to be for some reason (please explain), we leave it open. It has the FOR_RELEASENOTES9 Keyword. Release notes are for things-to-know which are not errors, of which 'remove-old-kernels'. It could have been introduced without a bug. ERRATA often has bug references.
I found a bug - not nasty but fixed in remove-old-kernels-0.99.1-4.mga9 Also: Added a CLI option to list the last 100 lines of the log. (-l) Added a shortcut symlink 'rok' => 'remove-old-kernels' to save typing. If auto is OFF it now shows in red on the status line. Added correction to man page - Running with '-a' manually does not get logged, only the cron job activity is logged. If people feel that it should be logged, then the urpmi output could be, but I'd rather not. It will be rarely used. One point that is a concern is that if you have masses of orphans, then these are listed to the log after each kernel is removed, so the log could expand rather quickly. Maybe it should also include a suitably timed logrotate in the future?
(In reply to Lewis Smith from comment #140) > (In reply to papoteur from comment #138) > > I think it should be kept open for release notes. > Do not see why; but if it needs to be for some reason (please explain), we > leave it open. > It has the FOR_RELEASENOTES9 Keyword. Release notes are for things-to-know > which are not errors, of which 'remove-old-kernels'. It could have been > introduced without a bug. ERRATA often has bug references. This should not be closed until it has been added to rpmsrate for Mga9.
urpme_old-kernels should be changed to require bootloader rather then grub2. On my m9 laptop which uses refind, I don't want to install grub2 as well.
(In reply to Dave Hodgins from comment #143) > urpme_old-kernels should be changed to require bootloader rather then grub2. > On my m9 laptop which uses refind, I don't want to install grub2 as well. Are you referring to urpme_old-kernels or remove-old-kernels. Both are currently in repos, but remove-old-kernels is the one we are working on to go forward, with the intention of obsoleting urpme_old-kernels before Mga9. Please try remove-old-kernels, which also currently requires grub2bootloader virtual require. If urpme actually works without grub2 then there is no reason not to relax the require to 'bootloader', as the script does not directly call any grub2 routines. It does use urpme. Obviously you will need to force install it manually without grub2*. Thanks for pointing this out.
(In reply to Barry Jackson from comment #144) > (In reply to Dave Hodgins from comment #143) > > urpme_old-kernels should be changed to require bootloader rather then grub2. > > On my m9 laptop which uses refind, I don't want to install grub2 as well. > > > Are you referring to urpme_old-kernels or remove-old-kernels. Both are > currently in repos, but remove-old-kernels is the one we are working on to > go forward, with the intention of obsoleting urpme_old-kernels before Mga9. > > Please try remove-old-kernels, which also currently requires grub2bootloader > virtual require. That's broken requires. we dont force grub2 on users > If urpme actually works without grub2 then there is no > reason not to relax the require to 'bootloader', as the script does not > directly call any grub2 routines. It does use urpme. > > Obviously you will need to force install it manually without grub2*. > > Thanks for pointing this out. Yes, urpme / urpmi manages just fine wthout grub2
I've now removed urpme_old-kernels which is the one that was pulling in grub2. Installing remove-old-kernels pulled in grub2-efi and grub2-common. Uninstalled grub2-efi and grub2-common using rpm -e --nodeps. remove-old-kernels appears to be working ok though there are no packages to remove. So remove-old-kernels should not require grub2bootloader. Since the basesystem package already requires a bootloader, the requires should be removed, not replaced with just bootloader. Regards, Dave Hodgins
remove-old-kernels-0.99.1-5 is now appearing on mirrors. Changes: - remove require on grub2bootloader - trim log to 1000 lines before each cron run - add French name to .desktop - fix potential colour bug - log -l option always displays mono and max 200 recent lines.
(In reply to Barry Jackson from comment #141) > One point that is a concern is that if you have masses of orphans, then > these are listed to the log after each kernel is removed, so the log could > expand rather quickly. I noticed this in my comment 131 test. I had wondered about offering 'urpme --auto-orphans' at the start of the process, but now think it does not matter. In the normal case where it is run weekly, you are unlikely to have (if any at all) more than 1 kernel to remove. It is only in one-off catch-up situations that you will have several kernels to remove, an ephemeral situation. In any case, you have already addressed the 'log' issue: > - trim log to 1000 lines before each cron run Where does Mageia 8 stand on this?
(In reply to Lewis Smith from comment #148) > > - trim log to 1000 lines before each cron run > > Where does Mageia 8 stand on this? Not sure I understand the question ;)
Time for me to run my kernel cleanup again. I currently have ... kernel-server-5.15.73-1.mga8-1-1.mga8 kernel-server-5.15.74-1.mga8-1-1.mga8 kernel-server-5.15.76-1.mga8-1-1.mga8 kernel-server-5.15.77-1.mga8-1-1.mga8 For qa team members, we often have kernel updates without the associated kernel module packages such as virtualbox-kernel. These happen when there the kernel updates are being done in stages to simplify testing. Only when tmb is ready are the kmod packages built. I think the most kernels I've seen built in a row without kmod packages (thus never passed on from updates testing to updates) was 4. We have to be careful not to remove the last kernel for which kmod updates were created. i.e. Then kernel and associated packages required by one of ... kernel-desktop-devel-latest kernel-desktop-latest kernel-desktop586-devel-latest kernel-desktop586-latest kernel-linus-devel-latest kernel-linus-latest kernel-linus-source-latest kernel-server-devel-latest kernel-server-latest kernel-source-latest virtualbox-kernel-desktop-latest virtualbox-kernel-server-latest xtables-addons-kernel-desktop-latest xtables-addons-kernel-desktop586-latest xtables-addons-kernel-server-latest Unless the script ensures none of those will be removed, qa team members will have to only run the script manually, and only when the latest kernel build also has the associated kmod packages.
(In reply to Dave Hodgins from comment #150) > Time for me to run my kernel cleanup again. I currently have ... > kernel-server-5.15.73-1.mga8-1-1.mga8 > kernel-server-5.15.74-1.mga8-1-1.mga8 > kernel-server-5.15.76-1.mga8-1-1.mga8 > kernel-server-5.15.77-1.mga8-1-1.mga8 > > For qa team members, we often have kernel updates without the associated > kernel module packages such as virtualbox-kernel. These happen when there > the kernel updates are being done in stages to simplify testing. Only when > tmb is ready are the kmod packages built. I think the most kernels I've > seen built in a row without kmod packages (thus never passed on from updates > testing to updates) was 4. > > We have to be careful not to remove the last kernel for which kmod updates > were created. > > i.e. Then kernel and associated packages required by one of ... > kernel-desktop-devel-latest > kernel-desktop-latest > kernel-desktop586-devel-latest > kernel-desktop586-latest > kernel-linus-devel-latest > kernel-linus-latest > kernel-linus-source-latest > kernel-server-devel-latest > kernel-server-latest > kernel-source-latest > virtualbox-kernel-desktop-latest > virtualbox-kernel-server-latest > xtables-addons-kernel-desktop-latest > xtables-addons-kernel-desktop586-latest > xtables-addons-kernel-server-latest > > Unless the script ensures none of those will be removed, qa team members will > have to only run the script manually, and only when the latest kernel build > also has the associated kmod packages. The script itself does not select any 'latest' packages for removal directly, however urpme will remove them if they depend on the kernel being removed.
That is a concern for qa members to use it regularly on a system they use for testing. Currently on m8 the kernel module packages such as the virtualbox-kernel packages were last built for the 5.15.74 kernels. Since then we've had 5.15.76 and currently have the 5.15.77 kernel packages. There will likely be at least one more before the kmod packages are built too and the packages considered for validation and being moved from updates testing to updates. If a script were run to keep just the last two kernels, it would remove the virtualbox kernel module package and the corresponding latest package, preventing future updates of it from being selected by mgaapplet unless the person noticed it and remembered to reinstall it after the kmod packages are built again. For qa team members to use it, it would have to ensure the kernel associated with the latest virtualbox-kernel-$version doesn't get removed. In my case I currently have virtualbox-kernel-server-latest-7.0.2-1.mga8 installed. The corresponding module package is virtualbox-kernel-5.15.74-server-1.mga8-7.0.2-1.mga8 (note the 7.0.2-1.mga8 on the end). So kernel 5.15.74 should not be removed even though there are two newer kernels.
(In reply to Dave Hodgins from comment #150) > We have to be careful not to remove the last kernel for which kmod updates > were created. > > Unless the script ensures none of those will be removed, qa team members will > have to only run the script manually, and only when the latest kernel build > also has the associated kmod packages. (In reply to Dave Hodgins from comment #152) > That is a concern for qa members to use it regularly on a system they use for > testing. > > For qa team members to use it, it would have to ensure the kernel associated > with the latest virtualbox-kernel-$version doesn't get removed. While this is technically a legitimate problem - and would it affect Cauldron users also? - I do not think it should impose on 'remove-old-kernels'. Its use is optional; it says what it proposes, and it is up to you to say yes or no; its automatic use can prevented; and you can uninstall it. This issue is in the hands of the user. What do people do now? Remove old kernels manually anyway; and if they do, they must be aware of the trap you describe. And people afflicted by the kmod business tend to know how to cope with it. > qa team members will have to only run the script manually, > and only when the latest kernel build also has the associated kmod packages Just so: in the hands of the user. What is noted here is completely par for the course. And a big improvement over the previous state of affairs. ---------------------------------------------------------------- (In reply to Barry Jackson from comment #142) > This should not be closed until it has been added to rpmsrate for Mga9. Apparently any packager (you?) can do this! (In reply to Barry Jackson from comment #149) > (In reply to Lewis Smith from comment #148) > > Where does Mageia 8 stand on this? > Not sure I understand the question ;) Oh! I meant is this planned to be offered for Mageia 8 also? (Backport). These users will be with us for some time yet, and are at present the most affected by old kernels. If this gets done, it warrants a Blog post. (For M9, it will be in Release Notes).
(In reply to Lewis Smith from comment #153) > (In reply to Dave Hodgins from comment #150) Thanks Dave I now have a better understanding of your concerns. It may be possible to avoid these by marking the related kernel as non-removable. I will see if it can be done without over complicating the script. Maybe a 'qa' flag in the config to enable it. > > Its use is optional; it says what it proposes, and it is up to you to say > yes or no; Not quite true. It says which kernels it proposes to remove but it does not know which other dependencies urpme may take with it in auto mode. In interactive mode using the 'i' response, urpme will ask before removal of the deps. Using the 'y' response will behave just like auto and remove all deps without asking. To avoid this issue for QA I would suggest that for now at least they should use the interactive mode only. Either from the GUI menu or by just typing 'rok' as root and when kernels are offered for removal use only the 'i' option. > (In reply to Barry Jackson from comment #142) > > This should not be closed until it has been added to rpmsrate for Mga9. > Apparently any packager (you?) can do this! I was not aware, however, I think this needs higher approval than just mine! > > (In reply to Barry Jackson from comment #149) > > (In reply to Lewis Smith from comment #148) > > > Where does Mageia 8 stand on this? > > Not sure I understand the question ;) > Oh! I meant is this planned to be offered for Mageia 8 also? (Backport). It has crossed my mind when it's finalized. > These users will be with us for some time yet, and are at present the most > affected by old kernels. > If this gets done, it warrants a Blog post. (For M9, it will be in Release > Notes). True, although I never think to read blogs as they are (were) always so far out of date. I doubt that the users that are worst affected by this even know there is a blog :\ @Lewis I will push a new version later today with, among a few other minor improvements, brighter screen colours (using light red and light green) which for me also looks better. Let me know what you think.
(In reply to Dave Hodgins from comment #152) > In my case I currently have virtualbox-kernel-server-latest-7.0.2-1.mga8 > installed. The corresponding module package is > virtualbox-kernel-5.15.74-server-1.mga8-7.0.2-1.mga8 (note the 7.0.2-1.mga8 > on the end). So kernel 5.15.74 should not be removed even though there are > two newer kernels. OK, taking the above situation only I have added protection for the packages that concern you. It grabs the vulnerable kernel version from the virtualbox-kernel-flavour-latest filename and marks the corresponding kernel and devel as not removable. (Sounds easy if you say it fast :) In the display they are shown as 'Needed by vbox' It seems to work OK as a first attempt and is the same as the version I pushed earlier to cauldron, except that this has QA=1 near the top of the spec. Without that or with QA=0 it behaves just like the latest version. http://mtf.duckdns.org/pub/linux/barjac/distrib/8/x86_64/media/extra/release/remove-old-kernels-0.99.1-7.mga.noarch.rpm It could stay in the script as a hidden feature, the QA=1 is also valid if added to the config file, and could be removed from the script hard settings. Let me know ;)
Dave, just to be clear the version in the repos does not have the QA code, it just 'behaves' the same without the QA switch.
For virtualbox, it's only on the x86_64 arch. virtualbox-kernel-desktop-latest virtualbox-kernel-server-latest On both x86_64 and i586 there are also xtables-addons-kernel-desktop-latest xtables-addons-kernel-server-latest On i586 only, there's also xtables-addons-kernel-desktop586-latest
OK thanks - This will take time, you could just set the limit to 15 ;) So is it working correctly with VBox as it is now?
I installed the remove-old-kernels-0.99.1-6.mga9.noarch.rpm package on my m9 system [root@x3 ~]# remove-old-kernels Number of kernels in /boot/ : 4 ==> kernel-server 1 : keep : kernel-server-5.15.77-1.mga8-1-1.mga8.x86_64 2022-11-05T16:13:04 EDT used now 2 : keep : kernel-server-5.15.76-1.mga8-1-1.mga8.x86_64 2022-10-29T17:53:13 EDT 3 : remove : kernel-server-5.15.74-1.mga8-1-1.mga8.x86_64 2022-10-15T20:32:14 EDT 4 : remove : kernel-server-5.15.73-1.mga8-1-1.mga8.x86_64 2022-10-13T16:15:46 EDT ==> kernel-server-devel 1 : keep : kernel-server-devel-5.15.77-1.mga8-1-1.mga8.x86_64 2022-11-05T16:12:48 EDT used now 2 : keep : kernel-server-devel-5.15.76-1.mga8-1-1.mga8.x86_64 2022-10-29T17:52:57 EDT 3 : remove : kernel-server-devel-5.15.74-1.mga8-1-1.mga8.x86_64 2022-10-15T20:32:12 EDT 4 : remove : kernel-server-devel-5.15.73-1.mga8-1-1.mga8.x86_64 2022-10-13T16:15:44 EDT ==> kernel-source 1 : keep : kernel-source-5.15.77-1.mga8-1-1.mga8.noarch 2022-11-05T16:13:01 EDT used now 2 : keep : kernel-source-5.15.76-1.mga8-1-1.mga8.noarch 2022-10-29T17:53:09 EDT 3 : remove : kernel-source-5.15.74-1.mga8-1-1.mga8.noarch 2022-10-15T20:32:26 EDT 4 : remove : kernel-source-5.15.73-1.mga8-1-1.mga8.noarch 2022-10-13T16:15:58 EDT Remove 6 kernels ? y/N/i (i=confirm for each) N Aborted [root@x3 ~]# urpme --test kernel-server-5.15.74-1.mga8-1-1.mga8.x86_64 To satisfy dependencies, the following 6 packages will be removed (80MB): kernel-server-5.15.74-1.mga8-1-1.mga8.x86_64 virtualbox-kernel-5.15.74-server-1.mga8-6.1.40-1.mga8.x86_64 (due to missing kernel-server-5.15.74-1.mga8, due to missing kernel-server-5.15.74-1.mga8[*]) virtualbox-kernel-5.15.74-server-1.mga8-7.0.2-1.mga8.x86_64 (due to missing kernel-server-5.15.74-1.mga8[*], due to missing kernel-server-5.15.74-1.mga8) virtualbox-kernel-server-latest-7.0.2-1.mga8.x86_64 (due to unsatisfied virtualbox-kernel-5.15.74-server-1.mga8 == 7.0.2-1.mga8) xtables-addons-kernel-5.15.74-server-1.mga8-3.21-1.6.mga8.x86_64 (due to missing kernel-server-5.15.74-1.mga8, due to missing kernel-server-5.15.74-1.mga8[*]) xtables-addons-kernel-server-latest-3.21-1.6.mga8.x86_64 (due to unsatisfied xtables-addons-kernel-5.15.74-server-1.mga8 == 3.21-1.6.mga8) Remove 6 packages? (y/N) n So it's not handling the latest packages yet.
No it does not handle 'latest' in remove-old-kernels-0.99.1-6.mga9.noarch.rpm which is stable and in repo. I don't want to delay or potentially break the main package with this extra feature, it may be added later. The WIP QA feature is only in 0.99.1-7 to which I linked above on my server just for you to test, it only looks for vbox as yet. It has a bug that I saw late last night that currently shows all kernels as non-removable when there is no vbox latest installed but that won't affect a quick initial test for you. Once tested more for vbox I can look at extending it to handle the others.
Created attachment 13489 [details] rok test script (qa) @Dave I just discovered a HD fail in my server so attaching the test script here. :(
Much better ... *** Welcome to 'remove-old-kernels' Interactive *** System: Mageia release 8 (Official) for x86_64 | Kernels in /boot/: 4 | AUTO: ON | KEEP: 3 ==> kernel-server 1 : keep : kernel-server-5.15.77-1.mga8-1-1.mga8.x86_64 2022-11-05T16:13:04 EDT In use now 2 : keep : kernel-server-5.15.76-1.mga8-1-1.mga8.x86_64 2022-10-29T17:53:13 EDT 3 : keep : kernel-server-5.15.74-1.mga8-1-1.mga8.x86_64 2022-10-15T20:32:14 EDT (vbox) 4 : remove : kernel-server-5.15.73-1.mga8-1-1.mga8.x86_64 2022-10-13T16:15:46 EDT ==> kernel-server-devel 1 : keep : kernel-server-devel-5.15.77-1.mga8-1-1.mga8.x86_64 2022-11-05T16:12:48 EDT 2 : keep : kernel-server-devel-5.15.76-1.mga8-1-1.mga8.x86_64 2022-10-29T17:52:57 EDT 3 : keep : kernel-server-devel-5.15.74-1.mga8-1-1.mga8.x86_64 2022-10-15T20:32:12 EDT (vbox) 4 : remove : kernel-server-devel-5.15.73-1.mga8-1-1.mga8.x86_64 2022-10-13T16:15:44 EDT ==> kernel-source 1 : keep : kernel-source-5.15.77-1.mga8-1-1.mga8.noarch 2022-11-05T16:13:01 EDT 2 : keep : kernel-source-5.15.76-1.mga8-1-1.mga8.noarch 2022-10-29T17:53:09 EDT 3 : keep : kernel-source-5.15.74-1.mga8-1-1.mga8.noarch 2022-10-15T20:32:26 EDT (vbox) 4 : remove : kernel-source-5.15.73-1.mga8-1-1.mga8.noarch 2022-10-13T16:15:58 EDT Remove 3 kernels ? y/N/i (i=confirm for each
Created attachment 13490 [details] rok test script _7.1 @Dave OK good - another to test, now it should catch the xtables as well.
I do not think I can be of any more use, signing out. Do please close this when everyone is satisfied.
CC: lewyssmith => (none)
Created attachment 13491 [details] Same as previous as text The previous not saved as text appeared to crash Firefox.
Attachment 13490 is obsolete: 0 => 1
With no kernel module packages installed and number to keep set at 2 ... 3 : remove : kernel-server-5.15.74-1.mga8-1-1.mga8.x86_64 2022-10-15T20:32:14 EDT With just xtables-addons-kernel-server-latest added ... 3 : keep : kernel-server-5.15.74-1.mga8-1-1.mga8.x86_64 2022-10-15T20:32:14 EDT (xtab) With virtualbox-kernel-server-latest added ... 3 : keep : kernel-server-5.15.74-1.mga8-1-1.mga8.x86_64 2022-10-15T20:32:14 EDT (vbox) The above looks good. The only other thing is that when the kernel is kept, the corresponding kernel devel package should probably be kept too. If the user installs a dkms package such as dkms-broadcom-wl, and boots that kernel for which the devel package has been removed, the dkms module will fail to build. That's minor and rarely likely to happen though, so it's up to you whether to add that logic or not.
I agree that it should be adequate for QA as it now is. I will push a package with the QA changes in a day or so, but with those features disabled by default. QA testers can 'turn the secret switch on' as required. :) Thanks for your help with this.
(In reply to Dave Hodgins from comment #166) > The above looks good. The only other thing is that when the kernel is kept, > the corresponding kernel devel package should probably be kept too. I have done this and it is now included in 'advanced mode' along with the kernels required by the vbox and xtables latest packages. Advanced mode is off by default but can be enabled with rok -Q1. The screen layout has changed slightly to show a column of key letters to indicate the reason for kernels being kept in advanced mode. This is all included in remove-old-kernels-0.99.2 which has just built in cauldron. Please read the updated man page and test as much as possible. Thanks, Barry
Assignee: mageiatools => zen25000
I'd forgotten to disable the prior version's cron job, so it ran yesterday morning. There were a couple more kernel builds for qa since comment 166. The most recent also has the kmod packages, so when it ran, it correctly only kept the most recent kernels and other packages. Just like with cauldron, the kernel packages that do not get moved to updates from updates testing are deleted when the next version is built, so they can not be reinstalled. It will take a while to test properly. The command users run is rok, so the man page should also be for rok as well as, or in place of remove-old-kernels. The file /etc/remove-old-kernels.cfg should probably be moved to /etc/sysconfig for consistency with other Mageia tools.
(In reply to Dave Hodgins from comment #169) > The command users run is rok, so the man page should also be for rok as well > as, or in place of remove-old-kernels. It is only a shortcut not a replacement, but I have added a symlink so 'man rok' works too and fixed the perms on the man file ;) > The file /etc/remove-old-kernels.cfg should probably be moved to > /etc/sysconfig > for consistency with other Mageia tools. Hmm... I would rather not, as it is already there on many systems. I would have to check where the .cfg is on update, and move it if necessary, since it is config(noreplace). As well as changing the docs. I will think about that one. Could cause more confusion than it's worth. I am adding a screen shot below to show how the xtables and vbox latest related kernels are handled on a test machine here.
Created attachment 13505 [details] Screenshot of 0.99.2-1 Screenshot in advanced mode.
I think that the main object of THIS bug report has been achieved so I am closing it as FIXED, since it's already too long ;) However the next step is to get this installed by default on all new systems to avoid the 'disk full' issue perpetuating. I have opened a new bug for that: https://bugs.mageia.org/show_bug.cgi?id=31143
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
silly question time. I have had a quick scan of the 172 comments and it didnt seem to show up. what happens if rok is used on a system that is 2nd'ry. sure, if grub2 is used by the 2nd'ry system, its config file is updated when the kernel is updated and rok is used to remove the older ones. how-ever, the primary system doesnt know about 2nd'rys systems new grub2 config file. this means that if the primary system is using grub2, it is possible that trying to boot into the 2nd'ry system will fail as the grub2 file (as seen by primary system grub) is now invalid if the primary system has not had its own grub2 updated.
(In reply to Ben McMonagle from comment #173) > silly question time. No not really :) > > I have had a quick scan of the 172 comments and it didnt seem to show up. > > what happens if rok is used on a system that is 2nd'ry. Then it will deal with that system's installed kernels. > > sure, if grub2 is used by the 2nd'ry system, its config file is updated > when the kernel is updated and rok is used to remove the older ones. Correct. > > how-ever, the primary system doesnt know about 2nd'rys systems new grub2 > config file. The secondary system's grub.cfg is never seen by the primary system. If update-grub2 is run on the primary system then the kernels in the secondary system will be found and added to the primary system's grub.cfg. > > this means that if the primary system is using grub2, it is possible that > trying to boot into the 2nd'ry system will fail as the grub2 file (as seen > by primary system grub) is now invalid if the primary system has not had its > own grub2 updated. Correct, this is only one of the reasons why it's a bad idea to use one system's boot loader to try to control another system. It has nothing to do with rok though, the same situation would apply however the 2nd system was modified or had kernels updated or removed. Have a look at: https://wiki.mageia.org/en/User_talk:Barjac
https://wiki.mageia.org/en/Mageia_9_Release_Notes#remove-old-kernels
Keywords: FOR_RELEASENOTES9 => IN_RELEASENOTES9