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): grub2-2.02-0.git9752.18.mga5 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. Reproducible: Steps to Reproduce:
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
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
(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.
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.
Agreed, Piotr, could you propose here a small text that I would copy to the Errata page?
Whiteboard: (none) => FOR_ERRATA
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
Version: 5 => CauldronCC: (none) => thierry.vignaudPriority: Normal => HighHardware: i586 => x86_64Whiteboard: FOR_ERRATA => FOR_ERRATA MGA5TOO
Yes the label doesn't match the kernel name as in grub-legacy/lilo thus we do nothing
Source RPM: grub2 => drakxtoolsAssignee: bugsquad => thierry.vignaud
(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?
Blocks: (none) => 416
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: %postun /sbin/bootloader-config --postremoval_cleanup Thomas: WDYT?
Summary: Removing kernel package didn't make update grub2 menu => Removing a kernel package doesn't update the grub2 menu
or for latest step: c) add this to grub2: %transfiletriggerpostun /sbin/bootloader-config --postremoval_cleanup (checking for /tmp/.post_kernel_remove_todo is bootloader-config job)
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: http://gitweb.mageia.org/software/drakx/commit/?id=f55d0d5edd7fb54198d43f64419291b93dca2346
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
You know this has not be done...
Or we could just change the kernels' %preun into %postun. Thomas, WDYT?
Source RPM: drakxtools => drakxtools, kernel
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
CC: (none) => fri
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
Whiteboard: FOR_ERRATA MGA5TOO => MGA5TOO
*** Bug 22536 has been marked as a duplicate of this bug. ***
CC: (none) => andrewsfarm
*** Bug 23250 has been marked as a duplicate of this bug. ***
CC: (none) => andre999mga
(In reply to Thierry Vignaud from comment #14) > Or we could just change the kernels' %preun into %postun. > Thomas, WDYT? To me that makes the most sense, since the issue is grub not being updated when a kernel is removed.
Still valid with Mageia 7 Cauldron. Removing MGA5TOO from the Whiteboard as MGA5 is EOL, and replacing it with MGA6TOO.
Whiteboard: MGA5TOO => MGA6TOO
Fixed in svn in Cauldron for kernel and kernel-linus in upcoming 5.5 series kernels... The same fixes will land in Mga7 when we switch to 5.5 series there too
Hardware: x86_64 => AllStatus: NEW => RESOLVEDWhiteboard: MGA6TOO => MGA7TOOResolution: (none) => FIXED
So fixed in Cauldron but still valid in Mageia 7 until kernel 5.5.
Version: Cauldron => 7Resolution: FIXED => (none)Whiteboard: MGA7TOO => (none)Status: RESOLVED => REOPENED
Fixed in kernel 5.4.17 in Cauldron and mga7 updates_testing
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Cool. I have one install where I've been neglectful of removing old kernels. Must be 5 or 6 piled up. I'll give it a test later today to confirm the fix.
As the postuninstall scriptlet is only executed when the kernel is removed, we won't be able to test this part of the kernel changes until 5.4.17-1 is one of the kernels being removed.
CC: (none) => davidwhodgins
well, you can always un-install the 5.4.17-1 again directly :)
OK then, here we go... Hardware: Intel i5 2500, 16GB RAM, integrated Intel graphics, wired Internet. 64-bit Plasma system. Installed kernel-desktop 5.4.17-1, rebooted, and checked it out. All was OK. Rebooted, this time back into the last kernel, kernel-desktop 5.4.12-something. Went to MCC, and removed all kernels other than 5.4.12-something in one operation, including 5.4.17-1, six kernels in all. This also removed the related vbox kmods. I did not do an "update-grub," contrary to what has become my usual practice. Rebooted, using the "Advanced" choice in grub2, which showed kernel-desktop 5.4.12-something and 5.4.10-something as potential choices. 5.4.10-something had definitely been removed. reboot into 5.4.12-something was successful. So, it failed to completely update grub2. Not entirely successful, but better than before. My guess would be that it "failed" because 5.4.17-1 wasn't the last kernel removed in the all-in-one operation.
(In reply to Thomas Andrews from comment #27) > OK then, here we go... > > So, it failed to completely update grub2. Not entirely successful, but > better than before. My guess would be that it "failed" because 5.4.17-1 > wasn't the last kernel removed in the all-in-one operation. Yep. since only 5.4.17-1 and newer trigger the updating of grub menu on uninstall, any older kernel removed after that does not get removed from the menu
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0073.html