Bug 9258 - Upgrade kernel and remove the old one
Summary: Upgrade kernel and remove the old one
Status: RESOLVED DUPLICATE of bug 24403
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal enhancement
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-05 11:41 CET by Pierre Bonneau
Modified: 2022-05-14 19:35 CEST (History)
10 users (show)

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


Attachments

Description Pierre Bonneau 2013-03-05 11:41:29 CET
Description of problem:
Today, when you upgrade your mageia installation, there is sometimes kernel update. But we never uninstall the old kernel.

It lead to different issues : 
 - a user trust one... we display lot's of kernel number in grub. For me, it's something that is not understaiable by the user. (this make no sence for a user who doesn't even know what kernel meant) And even if he knows, this easy access prove only that we don't trust mageia enough to update it without keeping backup for ever.
 - you add 30 / 50MB of datas for each kernel. I installed mageai on a partition of 5GB, so afetr 3 years, I have 20 kernels installed... for a total of 1GB... totally unuseful.
 - If you install your mageia like me, the old way with a /boot partition, you will fill this partition soon.(it prevent the RPM to install)

Version-Release number of selected component (if applicable):
1 - 2 cauldron...

How reproducible:
Install mageia and wait few month.

What I would find better : 
I have different options : 
-> to create a new kernel-latest with the new kernel and the previous one as a dependancy and all previous one as incompatible package.
-> to keep the actual system, but to move all old kernel to grub a specific submenu "old kernel version" or "backup kernel"
-> to trust the cauldron team enough to have only one kernel at a time(I personnaly didn't get any errors on trunk in 10 years updating the kernel that will prevent me to connect on linux). We could imagine a specific application accessible by grub to upgrade the kernel or downgrad it in case of broken access to the console.

I open the discussion... If you find any other ideas, I will be glad to discuss them with you.

Pierre

Reproducible: 

Steps to Reproduce:
Comment 1 James Kerr 2013-03-05 13:10:30 CET
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.
Comment 2 Anne Wilson 2013-03-05 13:50:17 CET
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

Manuel Hiebel 2013-03-05 17:23:13 CET

Component: New RPM package request => Release (media or process)
CC: (none) => sysadmin-bugs

Comment 3 paul nass 2013-03-16 07:35:57 CET
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

Comment 4 Marja Van Waes 2016-10-07 23:54:19 CEST
Assigning to the new default assignee for kernel bugs

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

Comment 5 Mauricio Andrés Bustamante Viveros 2018-03-11 07:56:07 CET
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

Comment 6 Frédéric "LpSolit" Buclin 2018-03-11 12:01:46 CET
(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.
Comment 7 Mauricio Andrés Bustamante Viveros 2018-03-11 14:12:47 CET
(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
Comment 8 Mark Dawson Butterworth 2018-03-22 13:25:32 CET
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

Comment 9 Pierre Bonneau 2018-03-22 14:21:56 CET
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.
Comment 10 Thomas Backlund 2018-03-22 18:21:36 CET
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

Comment 11 Mika Laitio 2018-04-02 01:14:24 CEST
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

Comment 12 Morgan Leijström 2018-05-29 20:45:02 CEST
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

Comment 13 Eric Petit 2018-07-25 19:58:45 CEST
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

Comment 14 sturmvogel 2022-05-14 19:35:17 CEST
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


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