Description of problem: During extensive VM testing of Mga5 EFI installations with multiple disks and multiple installations I came across this issue: [baz@localhost ~]$ su Password: [root@localhost baz]# grub2-install /dev/sda Installing for x86_64-efi platform. efibootmgr: Could not add entry to BootOrder: File exists Installation finished. No error reported. Clearing the list first as follows fixes this: [root@localhost baz]# efibootmgr -O BootCurrent: 0003 No BootOrder is set; firmware will attempt recovery Boot0000* EFI DVD/CDROM Boot0001* EFI Hard Drive Boot0002* EFI Hard Drive 1 Boot0003* EFI Internal Shell Boot0004* mageia [root@localhost baz]# grub2-install /dev/sda Installing for x86_64-efi platform. Installation finished. No error reported. [root@localhost baz]# I mentioned this to upstream grub2 and it was suggested that it should be reported as a grub2 bug, which I have not yet had time to do. I am still not sure if this has any actual adverse consequences, however it maybe should be fixed in the installer and in grub2-efi by adding a call to efibootmgr -O ahead of any grub2-install calls. @Thomas @Thierry WDYT? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
CC: (none) => thierry.vignaud, tmb
OK I now realize that this is probably invalid as I was miss-interpreting the message as meaning that the list existed, rather than the entry - which of course it does from installation. However there is another issue which I thought was related but now probably not - so I will re-use this report and change the title. After installing Mga5RC from classic DVD to a new drive in an existing EFI VM with other systems, boot fails with EFI unable to find the new drive's UUID. After chrooting into the new system from a live iso and running grub2-install /dev/sda update-grub a reboot gets as far as grub2, but that also fails to find the new drive's UUID: Welcome to GRUB! error: No such device: 0c1fcc..... Entering rescue mode... grub rescue> After chrooting into another Mga5 install in the VM and running grub2-install /dev/sda update-grub the other os boots into grub2 correctly and the new install is listed and boots, but only after a: 'device not found 0c1fcc.....' Press any key to continue... After a few seconds wait at this screen the boot continues normally. I am new to EFI and can only test in VM, so I don't know if anything here is a VBox bug.
Priority: Normal => HighSummary: Grub2/efibootmgr fail to add entry to boot order when list pre-exists => EFI boot error: no such device
Created attachment 5998 [details] Output of bootinfoscript
Note that the 'failing' boot is the most recently installed system on sdc with uuid 0c1eefec-13b5-421b-bdb4-6332ea44ef80
Created attachment 6000 [details] Output of bootinfoscript with /boot/EFI unmounted
Attachment 5998 is obsolete: 0 => 1
I cannot reproduce the issue referred to in #1,#2,#3 & #4 so dropping it, as it should have been a new report anyway. However the original bug does after all seem valid, so reverting subject/title. @marja please decide whether this is a duplicate of https://bugs.mageia.org/show_bug.cgi?id=14140
CC: (none) => marja11Summary: EFI boot error: no such device => efibootmgr: Could not add entry to BootOrder: File exists
(In reply to Barry Jackson from comment #5) > I cannot reproduce the issue referred to in #1,#2,#3 & #4 so dropping it, as > it should have been a new report anyway. > > However the original bug does after all seem valid, so reverting > subject/title. > > @marja please decide whether this is a duplicate of > https://bugs.mageia.org/show_bug.cgi?id=14140 Probably, but I'm not 100% sure, it depends on what efibootmgr does when being updated. I only know for sure this issue did cause https://bugs.mageia.org/show_bug.cgi?id=14779 but don't know how that was fixed/worked around. I filed this issue upstream, btw filed https://github.com/rhinstaller/efibootmgr/issues/24
See Also: (none) => https://github.com/rhinstaller/efibootmgr/issues/24
@ barjac this issue is still present, and nothing happened upstream since you straced efibootmgr -c ... [root@Mga5RC_EFI marja]# grub2-install Installing for x86_64-efi platform. efibootmgr: Could not add entry to BootOrder: File exists Installation finished. No error reported. [root@Mga5RC_EFI marja]# I think, as a workaroung, you suggested that it would be better to delete the BootOrder, before efibootmgr -c <etc.> When done manually, that fixes the problem. If someone finds time to patch grub2-efi with that workaround so that both * when it is updated, as well as * when grub2-install is called without grub2-efi just having been updated, efibootmgr -O is run before efibootmgr -c <etc.> then I'll test the package as soon as it lands on cauldron core/updates_testing
You cant wipe bootorder ("-O") on enduser systems... It will break stuff that worked before.
I pinged upstream bug.
Someone replied in upstream bug and I have patched it using his suggestion. Here in VM efibootmgr -o now works and grub2-install throws no errors. Please test efibootmgr-0.11.0-4.mga5 in updates_testing. @tmb Please check my patch as I'm not a C programmer ;)
Source RPM: grub2 => efibootmgr
(In reply to Barry Jackson from comment #10) > Someone replied in upstream bug and I have patched it using his suggestion. > Here in VM efibootmgr -o now works and grub2-install throws no errors. > you mean "-c" ?
Thanks, Barry :-D After installing efibootmgr-0.11.0-4.mga5.x86_64.rpm, the BootOrder list was still what it was before: 0008,000B,0012,0011 After then running "grub2-install" there was no more error, and the BootOrder list was 0012,0008,000B,0011 (Mageia had been added at the beginning of the list, which is what I had expected and consider correct) So as far as I'm concerned, this bug is fixed. However, I didn't reboot yet :-þ and I think it is good to get some more feedback, so not closing it yet
reboot went fine, too :-)
@Marja - you probably saw the reply in upstream bug. I have updated efivar locally and rebuilt efibootmgr against it without the patch that I applied previously. It seems OK here in a quick test. They are both available for test in this repo if you have time to test: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/media/extra/release I don't have time 'till later to push to updates_testing, but I will do this evening. @Thierry efivar is your package, but we are at 0.11 when 0.15 is current release I will commit the 0.15 and push to updates testing later unless you reply here beforehand.
I installed new efivar and lib64efivar (the first wasn't installed before, when I try again on another partition i'll make sure to only install the lib) then removed the Mageia entry from both the list of boot options and the BootOrder list, and after that re-added Mageia: [root@Mga5RC_EFI Downloads]# efibootmgr -b 0011 -B BootCurrent: 0011 Timeout: 0 seconds BootOrder: 000B,0008,0012 Boot0000 Setup Boot0001 Boot Menu <snip> Boot0010 Other HDD Boot0012* Windows Boot Manager [root@Mga5RC_EFI Downloads]# efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l \EFI\mageia\grubx64.efi BootCurrent: 0011 Timeout: 0 seconds BootOrder: 0011,000B,0008,0012 Boot0000 Setup Boot0001 Boot Menu <snip> Boot0010 Other HDD Boot0012* Windows Boot Manager Boot0011* mageia [root@Mga5RC_EFI Downloads]# With grub2-install, Mageia is correctly added to the BootOrder list, too.
Hi Marja thanks for testing, just to be sure you needed to install these two: lib64efivar0-0.15-1.mga5.x86_64 efibootmgr-0.11.0-6.mga5.x86_64 Is that what you did?
(In reply to Barry Jackson from comment #16) > Hi Marja thanks for testing, just to be sure you needed to install these two: > lib64efivar0-0.15-1.mga5.x86_64 > efibootmgr-0.11.0-6.mga5.x86_64 > Is that what you did? no, I didn't install new efibootmgr will try again asap
[root@Mga5RC_EFI marja]# rpm -qa | grep efi efibootmgr-0.11.0-6.mga5 grub2-efi-2.02-0.git9752.18.mga5 lib64efivar0-0.15-1.mga5 [root@Mga5RC_EFI marja]# the boot order was still OK after updating efibootmgr I removed mageia from the boot entries + the boot order again, and added her back without problems (the other boot order entries did not get lost, mageia was put in front of them as expected) I ran grub2-install without problems, too: afterwards, Mageia was still in the BootOrder
(In reply to Marja van Waes from comment #18) Great - thanks. I have pushed both packages to core/updates_testing.
(In reply to Barry Jackson from comment #19) > (In reply to Marja van Waes from comment #18) > Great - thanks. > I have pushed both packages to core/updates_testing. *Not* so great here: I had not tested rebooting, sorry :-[ When I wanted to start this laptop this morning, despite Mageia being first in the BootOrder list and being the first one that was in the UEFI("BIOS") list of bootloaders to be tried, Mageia couldn't boot. Should I have run update-grub in between, somewhere?
(In reply to Marja van Waes from comment #20) . > > Should I have run update-grub in between, somewhere? Ran update-grub2 and rebooted: still the Mageia bootloader wasn't used. Then ran grub2-install again and after that rebooting into Mageia was fine.
as asked by barjac on IRC, I now downgraded lib64efivar0 and efibootmgr, rebooted to see booting into Mageia still worked OK, and installed efibootmgr-0.11.0-6.mga5 efibootmgr-0.11.0-6.mga5 should have pulled in lib64efivar0-0.15-1.mga5, but it didn't, it didn't ask for it, didn't say it couldn't find it or anything like that. I still have lib64efivar0-0.11-4.mga5 now.
In the spec, I only see BuildRequires: pkgconfig(efivar) but nothing about efibootmgr requiring version > 0.14
So now you should have the original bug as new efibootmgr is just a reversion to as it was before the patch that temporarily fixed this. If you check for that and then install new lib64efivar0 the bug should be gone. I was mistaken about the required version being automatic - I think efibootmgr needs a hard require on the efivar version to be sure - thanks for checking that :)
(In reply to Barry Jackson from comment #24) > So now you should have the original bug as new efibootmgr is just a > reversion to as it was before the patch that temporarily fixed this. It doesn't work at all, instead of badly: [root@Mga5RC_EFI marja]# efibootmgr efibootmgr: symbol lookup error: efibootmgr: undefined symbol: efi_guid_zero [root@Mga5RC_EFI marja]# > > If you check for that and then install new lib64efivar0 the bug should be > gone. Only tested running "efibootmgr" without options, and that was fine. Will run some more tests now, and remember to reboot after each of them ;-)
i could reboot nicely into Mageia after the above. Then did "grub2-install" and rebooted fine. Then * "efibootmgr -b 0011 -B" * checked Mageia had disappeared from both the bootloader entries and the BootOrder list * ran "efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l \EFI\mageia\grubx64.efi" * checked that mageia had been correctly added back to both bootloaders entries and the BootOrder list * rebooting *failed* after running grub2-install again, rebooting into Mageia works fine. Maybe my memory that grub2-install didn't need to be run after the above efibootmgr commands, was wrong
I reproduced your issue, but just used your command without studying it too closely. In the 'BIOS' mageia is shown first in boot order but last in the list, and fails to boot. (openSuSE grub2 boots from where I can boot Mageia) Likewise running grub2-install fixes it. What's the output of df on that machine? Is your ESP really on partition 2? ...and I don't know what the -w 'unique signature' to MBR ?? is all about. I will dig more later. Still muck spreading - just came in for a brew.
(In reply to Barry Jackson from comment #27) > I reproduced your issue, but just used your command without studying it too > closely. > In the 'BIOS' mageia is shown first in boot order but last in the list, and > fails to boot. (openSuSE grub2 boots from where I can boot Mageia) > Likewise running grub2-install fixes it. > > What's the output of df on that machine? > Is your ESP really on partition 2? [marja@Mga5RC_EFI ~]$ df | grep EFI /dev/sda2 256M 52M 205M 21% /boot/EFI [marja@Mga5RC_EFI ~]$ > ...and I don't know what the -w 'unique signature' to MBR ?? is all about. Nor do I, I found "-w" when trying to figure out what grub2-efi did, in bug 1477 It was in grub2-2.00-mga-git-9752.patch The used command is based on tmb's reply here: https://bugs.mageia.org/show_bug.cgi?id=14779#c16: > The correct call would be: > > efibootmgr -c -d /dev/sda -p 2 -w -L mageia2 -l \EFI\mageia\grubx64.efi
Oops, make that bug 14779
Downgraded again to see what those two efibootmgr commands would do Exactly the same thing happened.... so whatever this is, it is *not* a regression
(In reply to Marja van Waes from comment #30) > Downgraded again to see what those two efibootmgr commands would do > > Exactly the same thing happened.... so whatever this is, it is *not* a > regression Thanks for doing that - I was planning to do the same. I think efibootmgr needs: Buildrequires: pkgconfig(efivar) >= 0.15 Requires: %{_lib}efivar0 >= 0.15 Then this is will be OK hopefully.
(In reply to Barry Jackson from comment #31) > > I think efibootmgr needs: > Buildrequires: pkgconfig(efivar) >= 0.15 > Requires: %{_lib}efivar0 >= 0.15 This is not needed, as soon as you push efivar 0.15 to core/release, the previous version will be removed.
CC: (none) => rverschelde
(In reply to Rémi Verschelde from comment #32) > (In reply to Barry Jackson from comment #31) > > > > I think efibootmgr needs: > > Buildrequires: pkgconfig(efivar) >= 0.15 > > Requires: %{_lib}efivar0 >= 0.15 > > This is not needed, as soon as you push efivar 0.15 to core/release, the > previous version will be removed. ...but if someone updates efibootmgr manually it should pull the correct version, or if mirrors are not up to date and new efivar is not there, the update of efibootmgr should fail. Without the Requires: it would install and be broken. Unless I'm missing something.
@marja This is interesting. I just compared (diff) the verbose output of efibootmgr in the 'broken'(-) state and the 'working'(+) state: -Boot0000* mageia HD(1,800,95800,58c33984-8d3e-4c0d-95f2-eaa0bef69935)File(EFImageiagrubx64.efi) +Boot0000* mageia HD(1,800,95800,58c33984-8d3e-4c0d-95f2-eaa0bef69935)File(\EFI\mageia\grubx64.efi) In the broken state all the path separators (\) are missing!
(In reply to Barry Jackson from comment #33) > (In reply to Rémi Verschelde from comment #32) > > (In reply to Barry Jackson from comment #31) > > > > > > I think efibootmgr needs: > > > Buildrequires: pkgconfig(efivar) >= 0.15 > > > Requires: %{_lib}efivar0 >= 0.15 > > > > This is not needed, as soon as you push efivar 0.15 to core/release, the > > previous version will be removed. > > ...but if someone updates efibootmgr manually it should pull the correct > version, or if mirrors are not up to date and new efivar is not there, the > update of efibootmgr should fail. Without the Requires: it would install and > be broken. > Unless I'm missing something. Well, what I mean is that it's cauldron. It's pretty normal when updating a package to also update the library that it links against, and we don't particularly specify versioned requires in such cases, since the older version is removed from the repo when the packages are pushed. The difference here is that you pushed efivar to core/updates_testing, so it did not remove the previous version. But the versioned requires does hurt anyway, so feel free to use it to make sure everything works as expected.
@marja \o/ Try this: efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l \\EFI\\mageia\\grubx64.efi Works for me :)
(In reply to Barry Jackson from comment #36) > @marja > \o/ > Try this: > efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l \\EFI\\mageia\\grubx64.efi > > Works for me :) Super! Is that how grub2-efi calls efibootmgr, with escaping the backslashes?
@Remi I think I prefer to use the Requires: in this case since there is no autorequire magic to rely on, especially as you say it does s//not/ hurt. :)
(In reply to Marja van Waes from comment #37) > (In reply to Barry Jackson from comment #36) > > @marja > > \o/ > > Try this: > > efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l \\EFI\\mageia\\grubx64.efi > > > > Works for me :) > > Super! > Is that how grub2-efi calls efibootmgr, with escaping the backslashes? No idea how grub2-efi does it. It just seemed possible, considering the diff that the backslashes were being seen as escapes. So it's not a bug :) I'll commit both and ask for a push.
Thanks, Barry :-)
(In reply to Marja van Waes from comment #40) > Thanks, Barry :-) Quotes work too: efibootmgr -c -d /dev/sda -p 2 -w -L "mageia" -l "\EFI\mageia\grubx64.efi" I updated this: https://wiki.mageia.org/en/Efibootmgr#Creating_a_boot_entry
(In reply to Rémi Verschelde from comment #32) > > Requires: %{_lib}efivar0 >= 0.15 > > This is not needed, as soon as you push efivar 0.15 to core/release, the > previous version will be removed. This is _needed_ so that when installkernel is run on upgrade, we're sure to have all the needed packages. Else you cannot guaranty that efivar will be updated before grub2/kernel. BTW, this is also why the added requires must be commented in the spec...
(In reply to Thierry Vignaud from comment #42) > BTW, this is also why the added requires must be commented in the spec... Done Closing then
Status: NEW => RESOLVEDResolution: (none) => FIXED