Bug 16268 - Removing a kernel package doesn't update the grub2 menu
Summary: Removing a kernel package doesn't update the grub2 menu
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High major
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
Whiteboard: MGA5TOO
Depends on:
Blocks: 416
  Show dependency treegraph
Reported: 2015-07-01 22:10 CEST by Piotr Mierzwinski
Modified: 2016-10-18 13:14 CEST (History)
4 users (show)

See Also:
Source RPM: drakxtools, kernel
Status comment:


Description Piotr Mierzwinski 2015-07-01 22:10:43 CEST
Description of problem:
On my PC I've activated grub2 (using mcc). I have legacy (integrated) nvidia graphics card. I've upgraded Mageia from version 5 rc to version 5 final release. As first was installed beta version. I found some issue in integration of grub2.
I had 3 kernels as follow
a. 3.19.7-server-2
b. 3.19.8-server-2
c. 3.19.8-server-3

Using rpmdrake I removed kernel "b" (including devel, virtualbox and nvidia304 packages) after restart I noticed that in advanced options of boot menu persists entry referring to removed kernel.

To be sure. I repeated operation. This time I've removed (using rpmdrake) kernel "a". After restart I noticed that disappeared entry referring to 3.19.8-server-2 (removed as first time), so "b" and left entry referring to recently removed, pointed in "a".

In similar operation, if active is grub1 then boot menu was properly updated, which means removed are entries referring to uninstalled kernels. I've tested it in Mageia 5 beta and rc version.
I think, boot menu should not have any entries referring to removed kernels.

Version-Release number of selected component (if applicable):

How reproducible:
Having couple of kernels please remove someone using rpmdrake. Restart system and look at advanced menu.

Steps to Reproduce:
1. run rpmdrake
2. select (and check) kernel which one want to remove (packages virtualbox and nvidia304 will be attached by dependencies)
3. select (and check) also kernel-devel
4. press Apply
5. quit rpmdrake
6. restart Mageia
7. being in boot menu go to advanced menu

Entry referring to removed kernel persists in menu.


Steps to Reproduce:
Comment 1 Piotr Mierzwinski 2015-07-01 22:48:24 CEST
Minor update due to my mistake.
  In one section is:
How reproducible:
Having couple of kernels please remove someone using rpmdrake. Restart system and look at advanced menu.
  and should be:
How reproducible:
every time
Comment 2 Samuel Verschelde 2015-07-02 09:04:38 CEST
Not assigning to someone in particular because I don't know if the culprit is the kernel packaging or grub2. Barry and Thomas, can you comment?

CC: (none) => tmb, zen25000

Comment 3 Barry Jackson 2015-07-02 15:52:06 CEST
(In reply to Samuel VERSCHELDE from comment #2)
> Not assigning to someone in particular because I don't know if the culprit
> is the kernel packaging or grub2. Barry and Thomas, can you comment?

This used to be handled by grub2 filetriggers which have been removed.

Now something in kernel packaging should handle it, however if the removed kernel was old then it may not have had this feature implemented anyway.

@Thomas ??

@Piotr Mierzwinski 
To correct your menu you can simply run update-grub in a terminal, which I guess you already knew, but mentioning here in case others hit this issue.
Comment 4 Piotr Mierzwinski 2015-07-03 01:19:05 CEST
Yes I did it :).

As I mentioned this happened in old kernels. I mean not the same as in released Mageia. I've upgraded system from rc version.
If I may suggest something. Some kind of solution would be a note in Errata page.
Comment 5 Samuel Verschelde 2015-07-03 10:27:26 CEST
Agreed, Piotr, could you propose here a small text that I would copy to the Errata page?

Whiteboard: (none) => FOR_ERRATA

Comment 6 Barry Jackson 2016-01-14 14:13:46 CET
Changing this to Cauldron and adding MGA5TOO in whiteboard and also increased priority as we don't want this happening Mga6.

I have just confirmed this behaviour in Cauldron when removing the current default kernel. The old default was still default on reboot despite it being removed.

So it seems to me that on kernel update or change via rpmdrake that grub2-install is being run but grub2-mkconfig is not.
See https://bugs.mageia.org/show_bug.cgi?id=17455

Could this be a simple typo somewhere in drakx-tools magic?

Adding tv to cc

Priority: Normal => High
CC: (none) => thierry.vignaud
Hardware: i586 => x86_64
Version: 5 => Cauldron

Comment 7 Thierry Vignaud 2016-01-14 18:38:42 CET
Yes the label doesn't match the kernel name as in grub-legacy/lilo thus we do nothing

Assignee: bugsquad => thierry.vignaud
Source RPM: grub2 => drakxtools

Comment 8 Rémi Verschelde 2016-01-15 14:31:58 CET
(In reply to Thierry Vignaud from comment #7)
> Yes the label doesn't match the kernel name as in grub-legacy/lilo thus we
> do nothing

I'm not sure if I fully understand, but what would needed to fix this issue then?

IIUC you say that it's normal that grub2-mkconfig is not run because the "label" does not match the uninstalled kernel name? What label are you referring to in this case?
Thierry Vignaud 2016-02-10 23:34:47 CET

Blocks: (none) => 416

Comment 9 Thierry Vignaud 2016-02-11 00:24:03 CET
There's 2 issues:

1) labels generated by grub2-mkconfig do not match labels generated by drakboot (such as used by grub-legacy/lilo)
I've patches for that. But:

2) installkernel (and thus bootloader-config) is called in kernel's %preun
Even if we did call update-grub2 at this stage, we would still generate a config including the kernel about to be removed...

Thus, with my local patches for 1st issue, if we remove a first kernel, grub2 config us updated too early but thus is kept as it was
When we remove a 2nd kernel, grub2 config us updated too early but at least the already removed 1st kernel is removed from the grub2's kernel list (but the 2nd removed kernel is obviously still there)

One solution is to:
a) I make bootloader-config --action remove-kernel writes a /tmp/.post_kernel_remove_todo file in grub2 case (ugly I know but that's the only way to communicate between %preun & %postun)
b) I add a postremoval_cleanup action to bootloader-config that check for /tmp/.post_kernel_remove_todo and calls modifybootloader() if it exists
c) we alter all our kernel so that they've a new scriptlet:
/sbin/bootloader-config --postremoval_cleanup

Thomas: WDYT?
Thierry Vignaud 2016-02-11 00:26:58 CET

Summary: Removing kernel package didn't make update grub2 menu => Removing a kernel package doesn't update the grub2 menu

Comment 10 Thierry Vignaud 2016-02-11 06:31:36 CET
or for latest step:
c) add this to grub2:
/sbin/bootloader-config --postremoval_cleanup

(checking for /tmp/.post_kernel_remove_todo is bootloader-config job)
Comment 11 Mageia Robot 2016-02-18 00:23:06 CET
commit f55d0d5edd7fb54198d43f64419291b93dca2346
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Wed Feb 10 23:48:28 2016 +0100

    just let grub2-mkconfig do its job for grub2
    remaining issue: we're calling update-grub2 too early, in kernel's
    %preun instead of its %postun... (mga#16268)
 Commit Link:
Comment 12 Barry Jackson 2016-05-22 17:20:46 CEST
Thierry, if the above has been implemented then it's not working, as update-grub2 is still not run on kernel removal.

Severity: normal => major

Comment 13 Thierry Vignaud 2016-05-22 17:33:54 CEST
You know this has not be done...
Comment 14 Thierry Vignaud 2016-06-22 00:58:27 CEST
Or we could just change the kernels' %preun into %postun.
Thomas, WDYT?

Source RPM: drakxtools => drakxtools, kernel

Comment 15 Thierry Vignaud 2016-06-22 01:10:06 CEST
More precisely, just move the installkernel from %preun to %postun
That means less calls to update-grub2 (which is slow in some cases)

BTW, the pushd/popd block of %preun looks useless, eg:
        if [ "" = "vmlinuz-4.6.2-desktop-2.mga6" ]; then

The following has been expanded too early:
if [ "$(readlink vmlinuz-$kernel_flavour)" 

I suggest:
if [ "\$(readlink vmlinuz-$kernel_flavour)"

Assignee: thierry.vignaud => tmb

Morgan Leijström 2016-07-10 18:49:30 CEST

CC: (none) => fri

Comment 16 Marja van Waes 2016-08-26 11:43:07 CEST
Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA.

Assignee: tmb => kernel

Samuel Verschelde 2016-10-18 13:14:42 CEST


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