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:
: 9258 29749 29943 (view as bug list)
Depends on:
Blocks: 22675
  Show dependency treegraph
 
Reported: 2019-02-22 09:25 CET by Jybz
Modified: 2022-08-16 21:52 CEST (History)
34 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
remove-old-kernels (script updated) (2.10 KB, application/x-shellscript)
2021-03-21 13:06 CET, Pierre Jarillon
Details
Remove old kernels with interactive modes (7.01 KB, application/x-shellscript)
2021-12-10 11:44 CET, Pierre Jarillon
Details
Script to keep only the most recently installed kernel and the kernel currently in use (1.14 KB, application/x-shellscript)
2022-01-26 22:04 CET, Julien Gouesse
Details
Pierre Jarillon script for removing old kernels (7.04 KB, application/x-shellscript)
2022-05-05 18:20 CEST, Rolf Pedersen
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.

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

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.

Priority: Normal => High
CC: (none) => ouaurelien
Blocks: (none) => 22675
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.
Comment 21 katnatek 2020-10-23 02:26:11 CEST
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
Comment 22 Bit Twister 2020-10-23 13:02:34 CEST
(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

Aurelien Oudelet 2021-01-02 18:58:51 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=27998

Comment 23 Mark Dawson Butterworth 2021-01-02 19:30:45 CET
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.

CC: (none) => mageia

Comment 24 Pascal Terjan 2021-01-04 16:08:32 CET
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

Comment 25 Pascal Terjan 2021-01-04 16:14:30 CET
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).
Comment 26 Bruno Cornec 2021-01-07 01:37:56 CET
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

Comment 27 Mészáros Csaba 2021-01-08 11:21:54 CET
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

Comment 28 chris matthews 2021-03-08 09:29:57 CET
(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

Comment 29 Pierre Jarillon 2021-03-21 13:06:55 CET
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

egc 2021-09-26 14:35:58 CEST

CC: (none) => egc

Comment 30 Morgan Leijström 2021-12-09 18:45:35 CET
*** Bug 29749 has been marked as a duplicate of this bug. ***

CC: (none) => joselpddj

Comment 31 Marc Krämer 2021-12-09 22:49:23 CET
@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.

CC: (none) => mageia

Comment 32 Jose Manuel López 2021-12-10 10:33:40 CET
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?
Comment 33 Marc Krämer 2021-12-10 10:51:18 CET
btw. can this script manage devel kernels as well?
Comment 34 Pierre Jarillon 2021-12-10 11:44:18 CET
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.
Comment 35 Chris Denice 2021-12-11 15:31:27 CET
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

Comment 36 Pierre Jarillon 2021-12-11 16:46:47 CET
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!
Comment 37 Dieter Schütze 2021-12-11 18:13:05 CET
(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.
Comment 38 Jose Manuel López 2021-12-13 09:01:49 CET
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!
Comment 39 Chris Denice 2021-12-13 11:44:33 CET
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.
Comment 40 Morgan Leijström 2021-12-13 12:15:08 CET
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?
Comment 41 Jose Manuel López 2021-12-13 13:58:15 CET
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!
Comment 42 Dieter Schütze 2021-12-13 18:14:06 CET
(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
Comment 43 Dieter Schütze 2021-12-13 18:18:13 CET
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 ;)
Comment 44 Morgan Leijström 2021-12-13 20:12:48 CET
(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.
Comment 45 Kristoffer Grundström 2021-12-14 01:47:09 CET
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.
Comment 46 Bruno Cornec 2021-12-15 01:00:27 CET
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
Comment 47 Pierre Jarillon 2021-12-15 13:11:49 CET
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
Comment 48 Jose Manuel López 2021-12-15 13:32:11 CET
I think that this package should go to testing repos too.
Comment 49 Jani Välimaa 2021-12-15 16:04:53 CET
(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

Comment 50 Giuseppe Ghibò 2021-12-15 16:44:31 CET
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

Comment 51 Dave Hodgins 2021-12-15 19:48:50 CET
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).
Comment 52 Florian Hubold 2021-12-15 22:54:25 CET
(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

Comment 53 Bruno Cornec 2021-12-15 23:35:05 CET
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.
Comment 54 Chris Denice 2021-12-16 10:00:04 CET
>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?
Comment 55 Morgan Leijström 2021-12-16 11:37:20 CET
(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.
Edward 2021-12-30 00:33:48 CET

CC: (none) => epp

Comment 56 Alex Kotov 2021-12-31 10:36:15 CET
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

Comment 57 Dimitrios Glentadakis 2022-01-01 06:44:20 CET
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

Comment 58 Morgan Leijström 2022-01-19 21:39:14 CET
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
Comment 59 Pierre Jarillon 2022-01-19 23:05:58 CET
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.
Comment 60 Dave Hodgins 2022-01-25 22:47:53 CET
*** Bug 29943 has been marked as a duplicate of this bug. ***

CC: (none) => gouessej

Comment 61 Julien Gouesse 2022-01-26 22:04:55 CET
Created attachment 13107 [details]
Script to keep only the most recently installed kernel and the kernel currently in use
Comment 62 Julien Gouesse 2022-01-26 22:10:47 CET
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?
Comment 63 Dimitrios Glentadakis 2022-02-06 05:19:33 CET
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.
Comment 64 Thomas Backlund 2022-02-06 13:30:39 CET
(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
Comment 65 Marc Krämer 2022-04-17 12:44:48 CEST
@Thomas: is there a way to have this feature in urpm* too? or will I have to use dnf instead?
Comment 66 Ben McMonagle 2022-05-05 02:24:48 CEST
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

Comment 67 Dave Hodgins 2022-05-05 03:00:40 CEST
It would need to be boot loader independent. I use refind on my uefi laptop.
Comment 68 Marc Krämer 2022-05-05 16:25:27 CEST
@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.
Comment 69 Rolf Pedersen 2022-05-05 18:20:44 CEST
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

Comment 70 Rolf Pedersen 2022-05-05 18:22:23 CEST
I had intended to indicate I've used the script regularly since last December 10.
Comment 71 Pierre Jarillon 2022-05-05 19:01:17 CEST
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.
Comment 72 Jose Manuel López 2022-05-06 17:27:05 CEST
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!!
Comment 73 Dimitrios Glentadakis 2022-05-06 19:20:26 CEST
Add to MCC a checkbox:
- Automatically remove old kernels
À spinbox :
- Number of kernels to keep
Comment 74 sturmvogel 2022-05-14 19:35:17 CEST
*** Bug 9258 has been marked as a duplicate of this bug. ***

CC: (none) => pmithrandir

John L. ten Wolde 2022-06-08 02:23:44 CEST

CC: (none) => johnltw

david Cossé 2022-08-02 10:35:44 CEST

CC: (none) => saveurlinux

Comment 75 Marc Krämer 2022-08-16 21:52:43 CEST
will we have this implemented in mga9??

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