This is a follow-up to bug 13901 where 2 issues have been fixed already and a third one remains. After removing the bootloader from NVRAM (I mean, in case it is technically incorrect "from the list of bootloaders the UEFI firmware is aware of so that it can offer to boot from them"), using for example "efibootmgr -O", the rescue mode is unable to restore it. Everything looks like it went fine, but the boot entry is not added back. See https://bugs.mageia.org/show_bug.cgi?id=13901#c23 and https://bugs.mageia.org/show_bug.cgi?id=13901#c26 Reproducible: Steps to Reproduce:
Priority: Normal => release_blockerBlocks: (none) => 416, 14069Assignee: bugsquad => thierry.vignaudSource RPM: (none) => drakx-installer-rescue
CC: (none) => rverschelde
If one just to flip the mode, as you said: * Switch to Legacy mode * Switch back to UEFI mode Then this looks more like a firmware bug to me if switching back & forth in firmware is enough to wipe the mageia entry without actually booting the OS...
CC: (none) => thierry.vignaud, tmb, zen25000Assignee: thierry.vignaud => bugsquad
> Then this looks more like a firmware bug to me if switching back & forth in firmware is enough to wipe the mageia entry without actually booting the OS... I agree that the way Stormi triggers his issue is likely to be a firmware bug. On the other hand, it would be nice if drakx-installer-rescue could handle this nevertheless. Upgrading Mageia 5 with the installer manages to restore the bootloader, and this bug is more of a feature request to let drakx-installer-rescue have the same feature.
(In reply to Thierry Vignaud from comment #1) > If one just to flip the mode, as you said: > * Switch to Legacy mode > * Switch back to UEFI mode > > Then this looks more like a firmware bug to me if switching back & forth in > firmware is enough to wipe the mageia entry without actually booting the > OS... Yes it is and I said it already. However, I'm not opening this bug report about a firmware bug, but because, if for whatever reason you lost your boot entry (erased by firmware, mine is not the only to do that, wiped by another OS, for example a windows "rescue"), rescue mode is unable to restore it. The installer can, rescue can't. Marja's tests demonstrate it and that's what the bug is about.
Strange. What the installer does is calling install_grub2() which: - calls write_grub2() which: o generates /boot/grub2/grub2.cfg o update /etc/default/grub, o update /boot/grub2/install.sh, - then call install_grub2 which runs /boot/grub2/install.sh Rescue only call the later, thus only run /boot/grub2/install.sh (like we run /boot/grub/install.sh for grub or lilo for lilo) Updating the other files shouldn't make a difference at all. What's in your /boot/grub2/install.sh ? Can you attach a screenshot of the rescue screen once it has finished restoring the bootloader?
Keywords: (none) => NEEDINFO
Created attachment 6268 [details] output of efibootmgr Here, both before and after testing, /boot/grub2/install.sh contains: grub2-install --grub-setup=/bin/true /dev/sda --directory /usr/lib/grub/x86_64-efi I'll attach a screenshot later, but I think the interesting part is the output of efibootmgr after rescue, so attaching that first. Not only is Mageia not in the BootOrder list, Mageia is not listed at all!
CC: (none) => marja11
Created attachment 6269 [details] screenshot after rescue finished
So maybe efibootmgr -c -d /dev/sdX -p Y -w -L mageia -l \EFI\mageia\grubx64.efi (X = disk letter Y = partion number) wasn't run? That command just correctly added Mageia as active entry in the list of efibootmgr entries, and also put it first in the BootOrder list
efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l \EFI\mageia\grubx64.efi wasn't enough to get the Mageia efi bootloader working again. After needed SuperGrub2disk again to boot into Mageia, I ran update-grub2 that didn't do the trick, either, but running grub2-install did, and now the Mageia bootloader is back and working :-) (Note that I chose to restore to a different partition than the one from which the bootloader had been created last)
Keywords: NEEDINFO => (none)
That's exactly what does /boot/grub2/install.sh So that's ought to work. What contains your /boot/grub2/install.sh?
(In reply to Thierry Vignaud from comment #9) > That's exactly what does /boot/grub2/install.sh > So that's ought to work. > What contains your /boot/grub2/install.sh? (In reply to Marja van Waes from comment #5) > > Here, both before and after testing, /boot/grub2/install.sh contains: > > grub2-install --grub-setup=/bin/true /dev/sda --directory > /usr/lib/grub/x86_64-efi > The "after" in that comment was before I ran update-grub and grub2-install. However, now it is still: grub2-install --grub-setup=/bin/true /dev/sda --directory /usr/lib/grub/x86_64-efi
It would be nice if some more (including me) could test whether doing a fast upgrade-install fixes the problem, like it did for stormi. That would make this bug less severe (at least for RC).
(In reply to Marja van Waes from comment #10) > However, now it is still: > > grub2-install --grub-setup=/bin/true /dev/sda --directory > /usr/lib/grub/x86_64-efi Can you reconfigure grub2 through drakboot with latest drakxtools, it should write a simpler install.sh I think rescue would then work.
Created attachment 6271 [details] screenshot of failed rescue (In reply to Thierry Vignaud from comment #12) > (In reply to Marja van Waes from comment #10) > > However, now it is still: > > > > grub2-install --grub-setup=/bin/true /dev/sda --directory > > /usr/lib/grub/x86_64-efi > > > Can you reconfigure grub2 through drakboot with latest drakxtools, it should > write a simpler install.sh It did, it then only contained: grub2-install > I think rescue would then work. However, rescue (using boot.iso, mirror updated this morning) gave an error now (tbh, I did not try whether it had worked despite the error it gave), see attached screenshot After fixing it with a fast upgrade install, which had no problem writing the bootloader, /boot/grub2/install.sh still contains only: grub2-install
Attachment 6269 is obsolete: 0 => 1
Please export as png next time, it's easier to handle. And smaller (which is nicer to bugzilla too) That grub2 error happens when one has grub2-efi installed but is not running in UEFI mode. Could you confirm you were not in UEFI mode? I think you've switched in the firmaware...
(In reply to Thierry Vignaud from comment #14) > Please export as png next time, it's easier to handle. And smaller (which is > nicer to bugzilla too) Will do :-) > That grub2 error happens when one has grub2-efi installed but is not running > in UEFI mode. > Could you confirm you were not in UEFI mode? > I think you've switched in the firmaware... Not according to the settings I see in the UEFI, they are still: UEFI/Legacy Boot [UEFI Only] - CSM Support [No] Besides, I did get the _EFI_bootloader_screen_ when booting boot.iso Also, the upgrade install I ran immediately afterwards did not have a problem writing the bootloader
However, I did use a boot.iso with "useless_thing_accepted", that can't mess this up, can it?
Hm, it just hit me... We only have grub2 on rescue media, not grub2-efi... And they can not be installed at the same time as they ship a lot of identical files... I haven't checked how much difference there is between them, but we need better packaging like splitting out identical files to a grub2-common package and so on...
And since afaik only the grub2-efi one will call out to efibootmgr...
No. Only changes in firmware are relevant. @Barry: should we mount other FSes for grub2-install to work in UEFI rescue? Such as /sys?
(In reply to Thomas Backlund from comment #17) > Hm, it just hit me... > > We only have grub2 on rescue media, not grub2-efi... Humm we run /boot/grub2/install.sh in the chroot, so that shouldn't matter.
Hm, we need access to /sys/firmware/efi
(In reply to Thierry Vignaud from comment #20) > (In reply to Thomas Backlund from comment #17) > > Hm, it just hit me... > > > > We only have grub2 on rescue media, not grub2-efi... > > Humm we run /boot/grub2/install.sh in the chroot, so that shouldn't matter. Ah, yes indeed so correct files are available.
Indeed mounting /sys in /mnt/sys fixes it
Created attachment 6272 [details] fix reinstalling grub2 on UEFI (mga#15695)
Created attachment 6273 [details] 1.51
Keywords: (none) => PATCH
commit 5095bce7a4c941684cf10cb1f671af9a7f90f110 Author: Thierry Vignaud <thierry.vignaud@...> Date: Wed Apr 15 07:14:17 2015 -0400 fix reinstalling grub2 on UEFI (mga#15695) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=5095bce7a4c941684cf10cb1f671af9a7f90f110
Thx, Thierry and Thomas :-D That fixed it. Closing, knowing that Stormi will reopen it if it didn't get fixed for him ;-)
Status: NEW => RESOLVEDResolution: (none) => FIXED