| Summary: | efibootmgr crashes with boot from usb | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Nikita Krupenko <krnekit> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | doktor5000, marja11, zen25000 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | efibootmgr-0.7.0-2.mga5.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: | Output and stacktrace | ||
|
Description
Nikita Krupenko
2014-10-05 13:00:19 CEST
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.
Florian Hubold
2014-10-08 21:19:49 CEST
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 =>
RESOLVED |