https://wiki.mageia.org/en/Feature:Limit_number_of_installed_kernels

That feature is listed as "pending"

https://wiki.mageia.org/en/FeatureMageia3_Review#Pending_features

which presumably means that it will be considered if and when resources are available to do so.

Fedora have limited the number of installed kernels to three for some years.  Old kernels are dropped as new ones are installed, so there is always a safe fallback if for any reason the newest kernel is not suitable.

The limit is set within a config file - /etc/sysconfig/something, IIRC, so where developers, for instance, require a number of different kernels installed it is a simple matter to increase that number.

I'm not aware of any problems that have been encountered with this system, so it remains a matter of resources to implement it.

CC: (none) => anne

fwiw, aptosid has a "kernel-remover" script.

I used aptosid for over 2 years. Started when it was still called sidux. And I did make use of the kernel-remover script. It allows you to select which kernels to remove. Typically I kept two older versions on my computer. 

http://manual.aptosid.com/en/sys-admin-kern-upg-en.htm#kern-remove

CC: (none) => pnass

Assigning to the new default assignee for kernel bugs

Assignee: bugsquad => kernel
CC: (none) => marja11
Component: Release (media or process) => RPM Packages

I suggest:

If kernel version is not the same branch as newest(example old=4.9.X and new=4.15.X)
Use the obsoletes to remove the oldest kernel that was available in the mirrors

If kernel version is same branch as newest, no remove oldest kernels

WHy?

Because in QA we require search for regresions (I do) we remember the behaviour of X kernel, if behaviour is changed (or may be the QA tester has doubts) the QA tester require the old kernels available to make comparisons, if we accept this enhancement or proposal as is, the QA team may not be able to do the correct work because they will end with few kernels to compare

CC: (none) => neoser10

(In reply to Mauricio Andrés Bustamante Viveros from comment #5)
> I suggest:
> 
> If kernel version is not the same branch as newest(example old=4.9.X and
> new=4.15.X)
> Use the obsoletes to remove the oldest kernel that was available in the
> mirrors

I disagree, this is not a good idea. For example, bug 21553 describes that newer kernels do not boot anymore in Virtualbox when you use 2 or more CPU. In that case, it is important to be able to use an older kernel which still works fine.

(In reply to Frédéric Buclin from comment #6)
> (In reply to Mauricio Andrés Bustamante Viveros from comment #5)
> > I suggest:
> > 
> > If kernel version is not the same branch as newest(example old=4.9.X and
> > new=4.15.X)
> > Use the obsoletes to remove the oldest kernel that was available in the
> > mirrors
> 
> I disagree, this is not a good idea. For example, bug 21553 describes that
> newer kernels do not boot anymore in Virtualbox when you use 2 or more CPU.
> In that case, it is important to be able to use an older kernel which still
> works fine.

Yeah Frederic, that was my point too, but I did not make statement for this because I can move the processor slider to 1 as workaround (I understand)

This proposal has many negative points... as QA team we must search this issues before the kernel package arrives to core/updates, some kernels has the security advisory caused by spectre and meltdown by example, these vbox not booting kernels   maybe are not release blockers for the update..... but is a release blocker for this proposal

Thanks for your point of view

I'd like to counter the suggestions that this is not necessary. For folk who have been persuaded to move from obsolete versions of a certain Microsoft product to Mageia as their OS for general computing, the issue here is that they expect the update/upgrade process to enable them to keep using their machine. What happens at the moment is, on machines with smaller disks, they run out of space on their root partition and bring their computer to me saying "its broken".

Even those of us who do know what we are doing have better things to do with our time than remove a load of kernels every 6 months or so (note that this would be a lot less painful if the confirm box for removing the corresponding VirtualBox kernel drivers didn't pop up every time). In answer to those who say not to bother deleting them at all, try a Mageia 5 to 6 upgrade on a machine with every Mageia 5 kernel version on and VirtualBox - the upgrade does a dkms update on every kernel, which takes a *long* time.

As an example, today I have been clearing up kernels on a computer which has had Mageia installed for less than 2 years. I have recovered more than 320M of root storage by removing old kernels, this on a machine which boots from a 3GB on-board Flash card so it matters. The other thing to bear in mind is that with VirtualBox the kernel additions take up considerably more space (1GB in this case) albeit on /usr not /.

I think I recall at some point in the past Marja had either suggested, or described someone else's suggestion, that we keep the four latest kernels (maybe I am misremembering this and it was that only four should appear in the boot menu). The arguments in this bug are convincing as to why this should not be done. However, I suggest that following Mauricio's approach may have merit. Why not keep all the current (x.y.<blah>) versions but only the last of previous (x-n).(y-n).<blah>?

e.g. for my activity today, rather than having every 4.4 since 30-2 (from Mageia 5), 4.9.56-1 (from Mageia 6), and every 4.14, I would instead have 4.4.105-1, 4.9.56-1, and all 4.14s.

Also, have a flag (visible in rpmdrake) to turn the functionality off for those who have a specific need (e.g. the VirtualBox CPU count issue which may persist across a "y" increment).

This does, of course, assume that the kernel versioning scheme doesn't change again upstream!

Incidentally, is it fluke that only the last 4.9 was present, or is Mageia 6 already doing something here anyway?

CC: (none) => mageia

Hello,

I really understand the problematic of QA, but they are very specific to a limited scope of user. Affecting all users to help a few who are part of the "build" team is usually a bad practice.


After, what we really need is to have a kernel previously installed in working condition. 
Therefore, I was wondering if we could simply put a rule : keep the number of kernel installed simultaneously under a numerical limit. (IE : Keep the last 5 kernel installed)

It would cover different use case, such as people upgrading after 2 years who would keep the very old kernel alongside the new one.

Yeah, we should really remove old/ancient kernels...

It only needs some clever coding to automate it, but to also allow people to select kernels they want to keep regardless of age...

CC: (none) => tmb

I agree with Thomas comment for having some mechanism to also allow keeping some old kernels for user just in case. (Maybe the olderst one that is installed should not be removed by the auto-remove feature?)

For example I encountered a problem with one machine which has been updated from mga4, mga5, mga6 cauldron and now finally to official mga6.

I had not booted the machine for a while and for some reason that machine started to scratch when launching login screen with every other kernels except the very old 3.19 series one which was leftover either from mga4 or mga5.

Machine had little older xeon cpus + nvidia card and in that case I believe the issue was related to loading of nouveau driver + using the 4k display. And at least for me the only way I got the system up was to boot first to 3.19 kernel where the nouveau did not crash on console, login to console and then select the vesa driver on mgaconf.
(Before doing that I was not able to find out any kernel parameters on grub to prevent nouveau driver to get loaded and crash the system)

I need to check that with some other display when I have time, but I believe that 4k reso was too much for Nouveau driver and made it crash with this GPU.

CC: (none) => lamikr

Idea that do not need GUI change:
User can indicate his favourites not to be removed by renaming the label using MCC -> Configure start, so the boot select label starts with a special character or word... "KEEP" maybe.

Then when there are more than X kernels installed, system automatically uninstalls the eldest which do not have that keyword, and it also do not uninstall the currently running kernel, and not the latest. (and maybe not the oldest too, and maybe not the second latest?)

Number of kernels to keep installed to be configurable. By making or setting something in some file.  If that is not made, default internally to i.e 5 kernels.

With the current large disks (even SSD and NVMe are large and relatively cheap today to what they were before) we do not need to throw out kernels too early.  Advanced users who have separate /boot or otherwise want to save disk space should be able to read up on how to change that setting.

"KEEP" keyword to have precedence over number of kernels to keep.

CC: (none) => fri

yes windaube is bad, but an option :
"start with the last good config know" 
?
just something like token, who say "this kernel is ok, and then keep this one, at each install of an kernel remove old one.

CC: (none) => surfzoid

Even if this bug was created earlier, there is already a big development for a kernel removal script in bug 24403. To streamline and channel all efforts i will mark this bug as dup of bug 24403

*** This bug has been marked as a duplicate of bug 24403 ***

Resolution: (none) => DUPLICATE
Status: NEW => RESOLVED