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 :
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.
(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.
anaselli, ngompa13, yves.brungard_mageiaAssignee:
Feature request : removing old kernels =>
Feature request : tool to remove old kernels
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?
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
@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.
(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
dnf repoquery --installonly
(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
> dnf repoquery --installonly
> tell me
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.
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.
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.
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.
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
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.
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 ?).
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.
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.