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.
Feature request : removing old kernels =>
Feature request : tool to remove old kernelsCC:
anaselli, ngompa13, yves.brungard_mageia
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.