| Summary: | Removing a kernel package doesn't update the grub2 menu | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Piotr Mierzwinski <piotr.mierzwinski> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | High | CC: | andr999, andrewsfarm, davidwhodgins, fri, thierry.vignaud, tmb, zen25000 |
| Version: | 7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | drakxtools, kernel | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 416 | ||
|
Description
Piotr Mierzwinski
2015-07-01 22:10:43 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 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 =>
Cauldron Yes the label doesn't match the kernel name as in grub-legacy/lilo thus we do nothing Source RPM:
grub2 =>
drakxtools (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 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?
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 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
Morgan Leijström
2016-07-10 18:49:30 CEST
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
Samuel Verschelde
2016-10-18 13:14:42 CEST
Whiteboard:
FOR_ERRATA MGA5TOO =>
MGA5TOO (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 =>
All So fixed in Cauldron but still valid in Mageia 7 until kernel 5.5. Version:
Cauldron =>
7 Fixed in kernel 5.4.17 in Cauldron and mga7 updates_testing Status:
REOPENED =>
RESOLVED 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 |