| Summary: | Grub2 changed EFI boot order in NVRAM, overriding rEFInd | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Maurice Batey <maurice77> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | marja11, zen25000 |
| Version: | 6 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | Log of Urpmi of Grand Update Saturday 28 July 2018 | ||
Corrected 'Component' to "RPM Packages" instead of erroneous "Request". Humble apologies... Component:
New RPM package request =>
RPM Packages This can't be caused by urpmi, nor by any KDE package. Please check which other packages were updated at the same time. Please open a konsole, become root and run, while replacing "YYYY" etc with real times: journalctl -a --since="YYYY-MM-DD hh:mm" --until="YYYY-MM-DD hh:mm" > log.txt and set the --since time to right before you started to do the grand update and the --until time to right after the grand update. Then attach log.txt to this bug report. (Compress with xz if it is too large to attach.) CC:
(none) =>
marja11 Created attachment 10301 [details]
Log of Urpmi of Grand Update Saturday 28 July 2018
Herewith terminal session log of Grand Update 20/7/2018
> while replacing "YYYY" etc with real times: > journalctl -a --since="YYYY-MM-DD hh:mm" --until="YYYY-MM-DD hh:mm" > log.txt > and set the --since time to right before you started to do the grand update > and the --until time to right after the grand update. I don't have precise Start/Finish times I'm afraid, though the date was July 28 and the date stamps on the attached text log file are: "Modified 18:03 Accessed 17:47" I just set it going and came back to find it done, perhaps 20-30 minutes later. Is there a way to find precise start/finish times of the Urpmi operation? > This can't be caused by urpmi, nor by any KDE package.
I have learned that although urpmi itself doesn't, the post-install script in the grub2 package does - but only if /usr/sbin/detectloader returns "GRUB2" (probably because there is /mageia/grubx64.efi in the ESP, which the rEFInd config has been told to ignore).
So, in effect, during a Urpmi s/w update, the boot order in NVRAM *can* get changed, even though the booted Mageia-6 doing the update was successfully booted by the previous non-Grub boot order.
I believe that is wrong; a user is surely entitled to assume a successful boot arrangement will not be changed...
(In reply to Maurice Batey from comment #5) > > This can't be caused by urpmi, nor by any KDE package. > > I have learned that although urpmi itself doesn't, the post-install script > in the grub2 package does - but only if /usr/sbin/detectloader returns > "GRUB2" (probably because there is /mageia/grubx64.efi in the ESP, which the > rEFInd config has been told to ignore). > > So, in effect, during a Urpmi s/w update, the boot order in NVRAM *can* get > changed, even though the booted Mageia-6 doing the update was successfully > booted by the previous non-Grub boot order. > > I believe that is wrong; a user is surely entitled to assume a successful > boot arrangement will not be changed... Afaics, we don't have a rEFInd package, I think it is a bit premature to expect our grub2-efi to not touch the NVRAM when rEFInd is used. There's bug 19949, asking for a more clear way to protect the NVRAM during Mageia install, and bug 15153 with patches to add support for the rEFInd boot manager in drakboot, but there's not even a package request for rEFInd! Not sure what to do with this report, assigning to the Mageia tools maintainers to decide. Keywords:
NEEDINFO =>
(none) > I think it is a bit premature to expect our grub2-efi to not touch the NVRAM
> when rEFInd is used.
But I might have been using any of a number of different boot managers!
This was a s/w update, not an Install (though even Mageia's installer does in fact provide an option to 'not touch the NVRAM'...)
To do the s/w update I booted Mageai-6 using the boot manager I have been happily using since first installing Mageia-6, in this case rEFInd.
I fail to see what business it is of a s/w update to mess with whatever boot arrangement I have set up and been happily using.
Surely its work should be confined to doing the update, not pontificating as to how my system is to boot next time?
In my view this is essentially a bug that should be fixed, before more irate users are affected!
Maurice, what do you have in /boot/grub2/install.sh? # cat /boot/grub2/install.sh grub2-install[root@pc18 ~]# There is your issue. It should contain: grub2-install --bootloader-id=tmp --no-nvram ... which is set up when the "Do not touch MBR etc." option is selected on install. > grub2-install --bootloader-id=tmp --no-nvram
>... which is set up when the "Do not touch MBR etc." option is selected
> on install
Never seen that mentioned anywhere before, but I see from my backup of
Mageia-6 on my Probook that it is there.
Presumably the reason it's not in the desktop's /boot/grub/install.sh is
because I didn't select that option, as the only system on the PC was
Windows10, no Linux in sight so no pre-set Linux booting to disturb, and I
was confident enough in the PC's UEFI firmware (ASUS Prime Z270-K mother
board) implementation that I could use efibootmgr later to set up booting
into rEFInd.
(Not so with the Probook.)
But regardless of whatever was put in /boot/grub/install.sh some months ago, I do not see why a s/w update should mess with the current boot setup.
Clearly the current boot setup worked; Mageia-6 was performing the s/w
update, so why should the reboot be forced into a Grub boot? What if I had
planned to next run e.g. SystemRescueDisk from a USB drive, which rEFInd
would automatically include in its boot menu?
I believe a s/w update should confine itself to doing just that, not
arbitrarily alter the current successful boot sequence.
Installers can perhaps be a bit more bossy!
I would guess that there was an update to grub2 itself involved, in which case it had to re-install it's modules and bootloader files. If it did not do this there could be a version mismatch which may break booting. How it does this is controlled by install.sh. > If it did not do this there could be a version mismatch which may break
> booting.
No problem with it doing that! As I said earlier, my boot sequence was ignoring the mageia grubx64.efi anyway, going straight to rEFInd.
I still fail to see why a s/w update should touch the current boot sequence in NVRAM.
(With some older UEFI firmware that could have screwed booting altogether.)
If a user is happy with his/her current boot sequence (after all, it did boot the Mageia-6 that was doing the s/w update), it should NOT be arbitrarily changed. Simple as that...
Watch out for more irate users if unrequested NVRAM changes continue to be made during s/w updates...
Maybe a note could be added in here: https://wiki.mageia.org/en/Mageia_6_Errata#Retaining_an_existing_third_party_bootloader ...to suggest that if an alternative unsupported 3rd party bootloader is added post-install then drakboot should be used to set the "Do not touch.." option to checked, to avoid this happening. But that is to do with the Mageia-6 *installer*, Barry. I have seen no justification whatsoever for a software *update* to change the NVRAM boot order, the current state of which the user has already chosen and has given no indication or approval for it to be changed. You know it works, because Mageia-6 is already booted and is performing a s/w update. Its re-writing of the /mageia/grubx64.efi file is of no concern to the current boot order, which can ignore the change. There is no option available in grub2-install (which must be used to re-install grub2 files after a grub2 update) that avoids re-writing the nvram. This has been discussed with upstream in the past and an option requested to avoid this, however so far it has come to nothing. The suggested workaround is to do exactly what we now do. That is to use --no-nvram and --bootloader-id=tmp which effectively creates a dummy entry which is ignored. > There is no option available in grub2-install (which must be used to > re-install grub2 files after a grub2 update) that avoids re-writing the nvram. But - you say - re-writing of the NVRAM *can* be avoided, by "the use of --no-nvram and --bootloader-id=tmp" (if users are informed of it). So it *does* check for one particular reason not to change NVRAM, but fails to also check whether or not an INSTALL or a SOFTWARE UPDATE is taking place... I have yet to see any rationale explaining why the NVRAM boot array has to be forced to boot Mageia when rebooting after a *software update* (other than "It has always been done"), given that the user has successfully booted the Mageia that is doing the update - regardless of *how* it was booted. > This has been discussed with upstream in the past and an option requested > to avoid this, however so far it has come to nothing. Well, it's good to hear that someone tried to get the thing corrected! Perhaps applying a bit more weight could do the trick? How best to do that? Regarding the legitimacy of using a boot loader other than Grub2, readers here might appreciate some references to others that have been using rEFInd: https://wiki.mageia.org/en/Feature:Support_rEFInd_boot_manager https://forums.mageia.org/en/viewtopic.php?f=29&t=8958 https://www.zdnet.com/article/experiments-with-my-new-laptop-linux-and-uefi / I simply don't know if the same hazard has crept into Mageia-7, but as I have seen no assurance that a s/w *update* on a UEFI boot system would under no circumstances disturb the NVRAM setting if it is set to boot the rEFInd Boot Manager, I am not inclined to close this bug. As there has been no such problem with Mageia-7 - nor with Cauldron - this bug caan be deemed Closed. Resolution:
(none) =>
FIXED |
Description of problem: After an otherwise successful Grand Update (700+ packages) of Plasma Mageia-6 UEFI installation, the UEFI boot order had been changed to /mageia/grubx64.efi from the previous setting of 'rEFInd'! Version-Release number of selected component (if applicable): urpmi-8.110-2.mga6.src.rpm How reproducible: Steps to Reproduce: 1. On real UEFI desktop hardware, do urpmi auto-update of UEFI-installed Plasma Mageia-6 2. On reboot, find that the UEFI bootloader has been changed from 'rEFInd' to /mageia/grubX64.efi. 3. [Status quo easily restored by issuing: # efibootmgr -c -d /dev/sdb -p 1 -l \\EFI\\refind\\refind_x64.efi ] N.B. The unwanted boot change did NOT occur when the same update was applied to a Plasma Mageia-6 UEFI install on an HP 450 Probook. However, there are 2 differences between the 2 machines: (1) The desktop has 2 drives, and the ESP is on the 2nd drive (sdb), whereas the Probook has only 1 drive (sda). (2) On the Probook, efibootmgr is completely ineffectual in making boot changes to the NVRAM - so it is possible that on that occasion for a boot change to have been issued without making any change. In what situations does urpmi need to attempt such a change?