Description of problem: I have laptop with GPT partition table on a hard drive and EFI boot. Secure boot is disabled. It has installed Windows 8.1 and Mageia Cauldron. When I boot from usb stick with Mageia and run efibootmgr, it crashes. Stack trace: Version-Release number of selected component (if applicable): 0.7.0-2.mga5 How reproducible: Always Steps to Reproduce: 1. Boot from usb stick with Mageia Cauldron 2. Add repositories 3. Install efibootmgr 4. Run efibootmgr -v Reproducible: Steps to Reproduce:
Created attachment 5476 [details] Output and stacktrace Added output and stacktrace from gdb.
Please test with efibootmgr-0.9.0-1.mga5 from core/updates_testing.
CC: (none) => zen25000
Tested on 0.9.0-1.mgs5 - no crashes. Also I see no more "(invalid optional data length)" at the end of the windows entry, that was on 0.7.0.
Copied from -dev ML to keep info in one place. From marja: ------------------------------------ > With new efibootmgr > > [marja@DenkBlok3Cauldron5a1 ~]$ rpm -qa | grep efibootmgr > efibootmgr-0.9.0-1.mga5 > [marja@DenkBlok3Cauldron5a1 ~]$ > > rebooted fine into GRUB2 and Mageia > (never added windows correctly to GRUB2, so didn't try to boot into > windows from there) > > After that I did "efibootmgr -n <number of Windows Boot Manager> to get > windows on next reboot. > > That worked fine, too > > After that, as expected, reboot gave me the GRUB2 menu again. > > Deleting the bootorder with > "efibootmgr -O" worked fine, too. > > Adding the new boot order with > "efibootmgr -o <hexnumber,hexnumber,hexnumber>" works better than one or > more updates ago, and more intuitively. > Last time I used it, that only worked, and very buggy, when the zeros at > the beginning of the numbers were removed. Now it works like a charm > with the complete numbers Forgot to say that it "efibootmgr -o" refused to work now with the zeros removed. However, "efibootmgr -n" works here both with the zeros-at-the-beginning and without. ----------------------------------
CC: (none) => marja11
(In reply to Nikita Krupenko from comment #3) > Tested on 0.9.0-1.mgs5 - no crashes. Also I see no more "(invalid optional > data length)" at the end of the windows entry, that was on 0.7.0. Thanks for testing.
From dev ml: I'm not up to speed with the "zeros thing" - so is the new version OK in this respect? Will the change in -o option affect any erratas/docs at all? Cheers, Barry **************************************************************************** the "man efibootmgr" synopsis is OK, it says "[ -o XXXX,YYYY,ZZZZ ... ]". However, example 3 further down in the man page isn't correct any more: "CHANGING THE BOOT ORDER Assuming the configuration in Example #1, efibootmgr -o 3,4 could be called to specify PXE boot first, then Linux boot." That should be "efibootmgr -o 0003,0004" now. I'm not aware of any other docs or erratas, and I don't think this should stop the upgrade of the package.
(In reply to Marja van Waes from comment #6) I filed a bug upstream about the man page: https://github.com/vathpela/efibootmgr/issues/12 I will ask for a freeze push on the package. Many thanks for your help :)
marja - you may want to comment in the upstream issue above as they say the leading zeros (or lack of) should not be an issue.
CC: (none) => doktor5000
(In reply to Barry Jackson from comment #8) > marja - you may want to comment in the upstream issue above as they say the > leading zeros (or lack of) should not be an issue. Done... didn't see how to reopen the report, though.
This bug was already fixed in efibootmgr-0.9.0-1.mga5, and the new issue is fixed in the package that is waiting to be freeze pushed see also bug 14140
Status: NEW => RESOLVEDResolution: (none) => FIXED