Bug 24403 - Feature request : tool to remove old kernels
Summary: Feature request : tool to remove old kernels
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 22675
  Show dependency treegraph
 
Reported: 2019-02-22 09:25 CET by Jybz
Modified: 2020-09-19 18:08 CEST (History)
11 users (show)

See Also:
Source RPM: Drakconf
CVE:
Status comment:


Attachments
Pierre Jarillon's remove-old-kernels script (1.76 KB, text/plain)
2019-02-23 09:14 CET, Marja Van Waes
Details
Another script to remove old packages such as kernels installed by a "latest" package (1.40 KB, text/plain)
2019-03-11 02:02 CET, Dave Hodgins
Details

Description Jybz 2019-02-22 09:25:55 CET
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 ?
Comment 1 Marja Van Waes 2019-02-23 09:14:13 CET
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

Comment 2 Marja Van Waes 2019-02-23 09:16:34 CET
(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.

Assignee: bugsquad => mageiatools
Summary: Feature request : removing old kernels => Feature request : tool to remove old kernels
CC: (none) => anaselli, ngompa13, yves.brungard_mageia

Comment 3 Angelo Naselli 2019-02-23 12:04:31 CET
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.
Comment 4 Angelo Naselli 2019-02-23 12:05:55 CET
That to say that if i added something for that on dnfdragora, only other distro could use it...
Comment 5 Kristoffer Grundström 2019-02-24 00:29:41 CET
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

Comment 6 Nicolas Lécureuil 2019-02-24 09:54:14 CET
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

Comment 7 Angelo Naselli 2019-02-24 10:57:23 CET
@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.
Comment 8 Nicolas Lécureuil 2019-02-24 11:25:22 CET
@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.
Comment 9 Neal Gompa 2019-02-27 13:36:11 CET
@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.
Comment 10 Dave Hodgins 2019-03-11 02:02:51 CET
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

Comment 11 Dieter Schütze 2019-06-11 16:13:29 CEST
(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

Comment 12 Neal Gompa 2019-06-19 02:46:16 CEST
(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...
Comment 13 katnatek 2019-06-19 19:06:43 CEST
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))
Comment 14 Barry Jackson 2019-08-05 13:50:52 CEST
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

Comment 15 Dieter Schütze 2019-08-10 00:40:23 CEST
at the past urpme --auto-orphans removes old kernels if they are not blocked in the config.
Comment 16 Barry Jackson 2019-08-10 13:18:03 CEST
(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

Comment 17 Dieter Schütze 2019-10-02 10:58:57 CEST
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 ?
Comment 18 Morgan Leijström 2019-10-04 12:31:52 CEST
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

Comment 19 Aurelien Oudelet 2020-08-17 15:03:52 CEST
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.

CC: (none) => ouaurelien
Blocks: (none) => 22675
Priority: Normal => High
Severity: normal => major

Comment 20 Aurelien Oudelet 2020-09-19 18:08:56 CEST
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.

Note You need to log in before you can comment on or make changes to this bug.