Not sure it is the same issue, but it is at least very similar:

After updating my EFI cauldron for (I think) the first time since packages rebuild started, the system boots directly into Windows without showing the GRUB2 boot menu at all.

(I stopped and restarted updating after, on the first try, it wanted to install a bunch of kernels - if not all of them - as dependencies. That didn't occur again.
I had never taken the needed step to correctly add Windows to the GRUB2 boot menu, hadn't needed windows at all since installing grub2-efi in January.)

I'm 99,99% sure I had already installed efibootmgr-0.7.0-1.mga5 before.

CC: (none) => marja11

Looks similar to my case. IIRC there was a huge update with many packages.

Also, when I mount EFI partition, it has mageia folder with grub file in it.

brw, booting cauldron with the SuperGrub2 disk works fine

(http://www.supergrubdisk.org/super-grub2-disk/ 

There'll be several ways to do it, I chose "boot manually...." "operating systems" and then arrow down till I saw the newest vmlinuz (or was it kernel?) on the correct partition (I didn't choose the same with "single" appended, because I suppose that is rescue mode)

Anyway, efibootmgr-0.7.0-1.mga5 was installed on the 7th of September, after which everything still worked fine.

My last updates before the ones I did this morning, were a bunch on the 17th of September.

s/brw/btw/

Created attachment 5447 [details]
grubx64.efi

Attaching the /boot/EFI/EFI/mageia/grubx64.efi that was created this morning

(It's a binary, don't know whether that is useful at all)

Maybe in my case, the grub2 menu is "visible" so shortly, that I don't see it at all.

Is that caused by the "0" timeout here, or is that unrelated?

[root@DenkBlok3Cauldron5a1 x86_64-efi]# efibootmgr 
BootCurrent: 0008
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0003,000F,0008,000B,0009,0011,0006,0007,000A,000C,000D,000E
Boot0000  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash Screen
Boot0003  Lenovo Diagnostics
Boot0004  Startup Interrupt Menu
Boot0005  Rescue and Recovery
Boot0006* USB CD
Boot0007* USB FDD
Boot0008* ATAPI CD0
Boot0009* ATA HDD0
Boot000A* ATA HDD1
Boot000B* USB HDD
Boot000C* PCI LAN
Boot000D* ATAPI CD1
Boot000E* ATA HDD2
Boot000F  Other CD
Boot0010  Other HDD
Boot0011* Windows Boot Manager
Boot0012* mageia
[root@DenkBlok3Cauldron5a1 x86_64-efi]#

I changed the Timeout with (as root) 
efibootmgr -T
efibootmgr -t10

(it didn't work without deleting the Timeout entry with efibootmgr -T first)

will reboot now

It does take longer to boot into windows, but instead of a boot menu I got a dark grey screen (didn't count whether it was exactly 10 seconds, though)

The grey screen instead of the bootloader screen is most probably a separate issue.

Funny, in the BIOS (or whatever it is called today), mageia used to be a separate entry, that used to get automatically put at the top of the Boot Priority Order list.

That entry is gone, now.

"mageia" isn't in the efibootmgr output anymore, either, instead of only its value being missing from the BootOrder list.

According to "man efibootmgr", to create a new entry it assumes that /boot/efi is my EFI system partition, and that it is mounted at /dev/sda1.

Neither is the case here, for me it is /dev/sda2 and /boot/EFI

cc'ing tv, because he touched efibootmgr some time ago, so he might have a good suggestion :-)

CC: (none) => thierry.vignaud

I have hit it too ~2 times since I switched to efi, but I cant reproduce on demand :/

I tried Super Grub 2 on usb flash drive, but for some reason my system does not even display it in selecting boot device menu. But I've found rEFInd image and it allowed me to boot my system.

Then I have got output of `efibootmgr -d /dev/sda -p 2 -v`:

BootCurrent: 0000
Timeout: 3 seconds
BootOrder: 0002,0000
Boot0000* USB HDD: Generic USB  SD Reader	ACPI(a0341d0,0)PCI(12,2)USB(0,0)HD(1,800,23df,597b1339-b2e9-4a4a-93a9-43668b258344)RC
Boot0001* Mageia	HD(2,c8800,96000,87e6552a-0f01-4a4c-970f-9e06a8745f88)File(\EFI\mageia\grubx64.efi)
Boot0002* Windows Boot Manager	HD(2,c8800,96000,87e6552a-0f01-4a4c-970f-9e06a8745f88)File(\EFI\Microsoft\Boot\bootmgfw.efi)(invalid optional data length)

And when I change boot order with the -o option, nothing changes - I see the same output.
The last line looked suspicious to me. I checked partition with fsck and it found errors. But after fixing errors, changing boot order still does no effect. And then I tried to delete boot order with -O and set proper order again with -o option. After that it finally been changed. And on reboot I've got Mageia in boot menu again!

I still see this warning about invalid optional data length and maybe I should remove this item and re-create it, but Windows boots without any problems.

I didn't manage to correctly add the Mageia entry back in the efibootmgr list (looking with -v, it showed some \EFI\RedHat\ or \EFI\redhat\ path), so I re-installed both grub2-efi and efibootmgr

After that, Mageia had the correct path. Then similar efibootmgr -O and -o steps as Nikita took, made the Grub menu on boot appear again.

Btw, Nikita, thx for telling you solved it like that. I had first, wrongly, tried with efibootmgr -o 0013,0008 instead of with efibootmgr -o 13,8 ... your success made me better read the man page ;-)

(In reply to Marja van Waes from comment #14)
In my case I used 0001,0002, so it should work with zeroes too :)

Comment on attachment 5447 [details]
grubx64.efi

Obsoleting, because there was nothing wrong with the attached /boot/EFI/EFI/mageia/grubx64.efi 
It was perfectly possible to select it using the supergrub2 disk, get the grub2efi bootloader exactly as it should be and start Mageia from it

Attachment 5447 is obsolete: 0 => 1

This was not really good, as I thought before. After I deleted boot order and added it again, Windows refused to boot due to a wrong or missing BCD. I booted from windows installation USB flash and it couldn't do anything with installed system, and said that windows partition is locked. Using ntfscheck and chkdsk not helped. The so-called "Push button reset" not worked also with the same boot error as windows.
To restore Windows one should get somewhere imagex.exe, boot from Windows installation media, go to console and restore *.wim image file from push button reset partition. Then issue in the console "bootrec /RebuildBcd".

There is another reason, why I think, that something bad with efibootmgr: it often crashes. The error is double memory free corruption. I'll provide some output if I catch it again. This often happens, when I boot from usb flash drive.

@ Nikita,

can't you even boot into windows (one time) after doing

efibootmgr -n2

?

For me "efibootmgr -n11" works fine to boot into windows on next boot.
After shutting down windows I get the Mageia Grub2-efi bootloader again.

About the segfaults, I doubt they are related to Mageia disappearing from the boot menu, so they should probably go into one or more separate bug reports.

I've only seen one
Sep 24 21:01:40 DenkBlok3Cauldron5a1 kernel: efibootmgr[10458]: segfault at 0 ip 00007fd6fa62259e sp 00007fff1c327f10 error 4 in libc-2.20.so[7fd6fa5a4000+1a8000]

did you have the segfaults in libc-2.20.so, too?

Is there a chance that there'll be no more segfaults after all packages have been rebuilt?

(In reply to Marja van Waes from comment #18)
> can't you even boot into windows (one time) after doing
> 
> efibootmgr -n2

I have not checked this. I reinstalled all and it works now. Also I still see in efibootmgr output "(invalid optional data length)" at the end of the windows item. And I not changed boot order, so may be it would be broken again if I change.

Is there any way to do a full snapshot of the EFI data (not ESP partition) and restore it back?

(In reply to Marja van Waes from comment #19)
> did you have the segfaults in libc-2.20.so, too?
> 
> Is there a chance that there'll be no more segfaults after all packages have
> been rebuilt?

I posted separate report for efibootmgr crashes: bug 14232

I hit this again with version efibootmgr-0.9.0-2.mga5

This time it deleted Mageia and Windows from the boot order, and only kept the 2nd entry, boot from ATAPI CD0

Summary: After update Mageia disappeared from EFI boot menu => boot order settings lost when updating efibootmgr
Source RPM: efibootmgr-0.7.0-2.mga5 => efibootmgr-0.9.0-2.mga5

(Now wondering whether windows was the 2nd entry right before the first time I hit this bug)

Yesterday I installed updates (~850 packages) and Mageia disappeared from boot menu again. The first entry was Windows, the second one - Mageia. Now I see only Windows.

(In reply to Nikita Krupenko from comment #24)
> Yesterday I installed updates (~850 packages) and Mageia disappeared from
> boot menu again. The first entry was Windows, the second one - Mageia. Now I
> see only Windows.

Assuming you can somehow boot into Mageia, what is the output of:

su
os-prober

Output of os-prober:

Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows

Also I found, that I have grub1 installed besides grub2-efi.

@ Nikita
Did Mageia completely disappear from the efibootmgr output, or did it only disappear from the BootOrder list?

If it disappeared completely, then I'm not sure you hit the same bug now (in comment 13 it had only disappeared from the efitbootmgr boot order for you, but it was still an active entry in the list)

@ barjac,

for me, but *after* restoring the efibootmgr boot order, both Mga and Windows are shown with os-prober. I don't know what it was like before.

[root@DenkBlok3Cauldron5a1 marja]# os-prober
/dev/sda11:Mageia 5 (5):Mageia:linux
Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows
[root@DenkBlok3Cauldron5a1 marja]#

This is with both the pre-second-rebuild os-prober and with the new one, which I installed just now.

(In reply to Marja van Waes from comment #27)

> 
> @ barjac,
> 
> for me, but *after* restoring the efibootmgr boot order, both Mga and
> Windows are shown with os-prober. I don't know what it was like before.
> 
> [root@DenkBlok3Cauldron5a1 marja]# os-prober
> /dev/sda11:Mageia 5 (5):Mageia:linux
> Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows
> [root@DenkBlok3Cauldron5a1 marja]#
> 

OOPS
 However, that Mageia is a completely failed EFI-install, where the EFI part didn't work. The one I'm using now (and which boots fine since the BootOrder list was restored) is on a different partition!

Should os-prober work at all with EFI installs?

((In reply to Marja van Waes from comment #27)
> @ Nikita
> Did Mageia completely disappear from the efibootmgr output, or did it only
> disappear from the BootOrder list?

Only from boot order. After I deleted boot order and re-added it using efibootmgr, Mageia is shown in boot menu again.

> for me, but *after* restoring the efibootmgr boot order, both Mga and
> Windows are shown with os-prober. I don't know what it was like before.

After restoring boot order I still see only Windows here.

(In reply to Nikita Krupenko from comment #29)

> 
> After restoring boot order I still see only Windows here.

Yeah, so for both of us, os-prober doesn't show the Mageia partition we use

I'm wondering whether having 
http://sourceforge.net/projects/os-prober-efi/

might help in any way for the "mageia disappears from BootOrder list" issue

os-prober-efi seems dead btw, or it moved somewhere else and I can't find it

(In reply to Marja van Waes from comment #31)
> os-prober-efi seems dead btw, or it moved somewhere else and I can't find it


Yes, it seems unloved.
If you want to test, I made a quick package here:

http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/media/extra/release/os-prober-efi-0.1.3-1.mga5.noarch.rpm

Created attachment 5511 [details]
os-prober-efi (--force) output

@ barjac

Maybe it's dead because it doesn't work, and no one knows how to fix it?

See attachment.

However, if it worked, would it help for this bug? The problem in this bug report is only that Mageia disappeared from the _efibootmgr_boot_order_list_ (so the Grub2-efi bootloader wasn't reached... Mageia needs to be either first in the efibootmgr boot order list, or only after one or more currently not available DVD or USB entries, for the Grub2 bootloader to be reached). It was still in the _full_ efi-bootmgr's list, though, and even marked active. 

I'm sure Mageia was still in the Grub2-efi bootloader list itself, because I didn't regenerate it this time after repairing the BootOrder list and because the first time I hit this bug, one time I successfully used SuperGrub2 disk to use the Grub2-efi bootloader (so a good Mageia entry was still in it)

@ barjac

Btw, thanks for all your effort to help fix this bug!

Increasing priority

Priority: Normal => High

The bigger problem we have is that current grub2/os-prober setup is crap.

It probes everything under the sun and changes stuff on a whim...

And we need to nuke grub2 filetriggers as they also make a mess on a running system.

For example on a system installed from live that has grub configured as boot loader (and grub2 also installed (as we have had to force install it on live image as it wont install from live mode) but not configured), installing a
kernel will make grub2 silently replace grub as boot loader, wich is a big no-no.

anyway, started a wiki page for EFI users who can't boot into Mageia any longer and need to put Mageia back in the BootOrder list (this report has become too long to refer to from the errata)

https://wiki.mageia.org/en/EFI:_can_no_longer_boot_into_Mageia
Feel free to correct or improve it where needed

(In reply to Thomas Backlund from comment #35)
> The bigger problem we have is that current grub2/os-prober setup is crap.
> 
> It probes everything under the sun and changes stuff on a whim...
> 
It creates a menu including the systems it finds - hardly a whim ;)

> And we need to nuke grub2 filetriggers as they also make a mess on a running
> system.
>
How?

> For example on a system installed from live that has grub configured as boot
> loader (and grub2 also installed (as we have had to force install it on live
> image as it wont install from live mode) but not configured), installing a
> kernel will make grub2 silently replace grub as boot loader, wich is a big
> no-no.

No.
Grub2 filetrigger only re-generates the menu (grub.cfg) to include the new kernel version - it does not run grub2-install and so will not overwrite an existing grub legacy bootloader.

(In reply to Barry Jackson from comment #37)
> (In reply to Thomas Backlund from comment #35)
> > The bigger problem we have is that current grub2/os-prober setup is crap.
> > 
> > It probes everything under the sun and changes stuff on a whim...
> > 
> It creates a menu including the systems it finds - hardly a whim ;)
> 

Do you really think its good design to probe everyting under the sun when we know exactly what happends on a kernel install...


> > And we need to nuke grub2 filetriggers as they also make a mess on a running
> > system.
> >
> How?
> 
> > For example on a system installed from live that has grub configured as boot
> > loader (and grub2 also installed (as we have had to force install it on live
> > image as it wont install from live mode) but not configured), installing a
> > kernel will make grub2 silently replace grub as boot loader, wich is a big
> > no-no.
> 
> No.
> Grub2 filetrigger only re-generates the menu (grub.cfg) to include the new
> kernel version - it does not run grub2-install and so will not overwrite an
> existing grub legacy bootloader.

Actually it seems to be grub2 rpm...

It happends atleast on mga4 to cauldron update
after I updated the system I decided to urpme grub2 (as I dont use it) and on next boot no working bootloader :/

I had to boot from live media and chroot into the system and trigger /boot/grub/install.sh to fix up the borkage... (and yes grub legacy was still installed)

(In reply to Marja van Waes from comment #33)
> Created attachment 5511 [details]
> os-prober-efi (--force) output
> 
> @ barjac
> 
> Maybe it's dead because it doesn't work, and no one knows how to fix it?
> 
> See attachment.

Couldn't find "grub-probe" error is because we use 'grub2-probe'
Couldn't find "lsdisk" is an optional require which I didn't include as we don't have it.
Couldn't find EFI System Partition (ESP): "/EFI"  --------- What do we use?

I patched the s/grub/grub2/ in this:
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/media/extra/release/os-prober-efi-0.1.3-2.mga5.noarch.rpm

> 
> However, if it worked, would it help for this bug? 
Maybe not :\

Created attachment 5512 [details]
New os-prober-efi (--force) output

(In reply to Barry Jackson from comment #39)

> 
> Couldn't find "grub-probe" error is because we use 'grub2-probe'
> Couldn't find "lsdisk" is an optional require which I didn't include as we
> don't have it.
> Couldn't find EFI System Partition (ESP): "/EFI"  --------- What do we use?

we mount it on /boot/EFI, I'll attach a "find /boot/EFI" in next comment
> 
> I patched the s/grub/grub2/ in this:
> http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/media/extra/
> release/os-prober-efi-0.1.3-2.mga5.noarch.rpm

tried it, see new attachment
 
> > However, if it worked, would it help for this bug? 
> Maybe not :\

Thanks anyway (and thx Thomas, too)

Attachment 5511 is obsolete: 0 => 1

Created attachment 5513 [details]
"find /boot/EFI" output

@ barjac

hope this output helps

(In reply to Thomas Backlund from comment #38)

> 
> It happends atleast on mga4 to cauldron update
> after I updated the system I decided to urpme grub2 (as I dont use it) and
> on next boot no working bootloader :/
> 
> I had to boot from live media and chroot into the system and trigger
> /boot/grub/install.sh to fix up the borkage... (and yes grub legacy was
> still installed)

There was an issue when upgrading with an installed but unused grub2 - this was fixed, but maybe *after* your experience of it. It was part of:

https://bugs.mageia.org/show_bug.cgi?id=12423

Now on update grub2 checks that the current bootloader in MBR is grub2 before re-installing itself (which it must do to keep the version in MBR in sync with the installed system files). If it's not the current bootloader then only core.img is updated so that it can still be multi-booted from grub legacy.

(In reply to Barry Jackson from comment #42)
> (In reply to Thomas Backlund from comment #38)
> 
> > 
> > It happends atleast on mga4 to cauldron update
> > after I updated the system I decided to urpme grub2 (as I dont use it) and
> > on next boot no working bootloader :/
> > 
> > I had to boot from live media and chroot into the system and trigger
> > /boot/grub/install.sh to fix up the borkage... (and yes grub legacy was
> > still installed)
> 
> There was an issue when upgrading with an installed but unused grub2 - this
> was fixed, but maybe *after* your experience of it. It was part of:
> 
> https://bugs.mageia.org/show_bug.cgi?id=12423
> 
> Now on update grub2 checks that the current bootloader in MBR is grub2
> before re-installing itself (which it must do to keep the version in MBR in
> sync with the installed system files). If it's not the current bootloader
> then only core.img is updated so that it can still be multi-booted from grub
> legacy.

Hm, is not that fix included in Cauldron ?

I installed a Mga 4.1 and updated to Cauldron.

I see we pushed the grub2 fix on Aug 8th
http://advisories.mageia.org/MGAA-2014-0155.html

(In reply to Thomas Backlund from comment #43)

> Hm, is not that fix included in Cauldron ?

Yes

> 
> I installed a Mga 4.1 and updated to Cauldron.
> 
> I see we pushed the grub2 fix on Aug 8th
> http://advisories.mageia.org/MGAA-2014-0155.html

So let me get this right:

1. Install mga4.1
2. Install grub2 (package) manually (outside drakboot)
3. Upgrade to mga5
4. Reboot
5. Check that it boots (using grub legacy) correctly

Is that correct?

That was the procedure (although mga3 -> mga4) that QA used to test the update.

(In reply to Barry Jackson from comment #44)
> (In reply to Thomas Backlund from comment #43)


> 1. Install mga4.1
> 2. Install grub2 (package) manually (outside drakboot)
> 3. Upgrade to mga5
> 4. Reboot
> 5. Check that it boots (using grub legacy) correctly
> 
> Is that correct?

Nope.

1. Install mga4.1 from live media (contains both grub and grub2), and configure grub as bootloader
2. reboot and confirm grub is used. 
3. Upgrade to mga5 with urpmi and urpme grub2 at the end
4. Reboot and poof, grub is borked

(In reply to Marja van Waes from comment #41)
> Created attachment 5513 [details]
> "find /boot/EFI" output
> 
> @ barjac
> 
> hope this output helps

Try this: (s/\/EFI/\/boot\/EFI/)

http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/media/extra/release/os-prober-efi-0.1.3-3.mga5.noarch.rpm

But I agree - I think it's value is limited.

Created attachment 5514 [details]
os-prober-efi-0.1.3-3 output

(In reply to Barry Jackson from comment #46)

> 
> Try this: (s/\/EFI/\/boot\/EFI/)
> 
> http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/media/extra/
> release/os-prober-efi-0.1.3-3.mga5.noarch.rpm

That's better, but maybe the --force switch should be used by default?

> 
> But I agree - I think it's value is limited.

Well, just limited for this bug.

However, so far Mageia EFI installs didn't correctly add windows to the GRUB2 boot menu. I suppose it would be helpful with that :-)

(Hope no one notices how many issues we mix in this report ;-) )

Attachment 5512 is obsolete: 0 => 1

(In reply to Marja van Waes from comment #47)

> 
> However, so far Mageia EFI installs didn't correctly add windows to the
> GRUB2 boot menu. I suppose it would be helpful with that :-)
> 


@ barjac

I'll file a separate bug report tomorrow evening if you agree os-prober-efi could help solve that

(In reply to Thomas Backlund from comment #45)

> Nope.
> 
> 1. Install mga4.1 from live media (contains both grub and grub2), and
> configure grub as bootloader
> 2. reboot and confirm grub is used. 
> 3. Upgrade to mga5 with urpmi and urpme grub2 at the end
> 4. Reboot and poof, grub is borked

I just did the above and grub legacy boots normally.
During upgrade the output after grub2 update was:

"MBR not grub2 so skipping grub2-install"

Which is correct.

I did of course re-boot immediately after upgrade to check it was still booting with legacy. I then 'urpme grub2'  and rebooted again - no issues.

(In reply to Marja van Waes from comment #48)
> 
> I'll file a separate bug report tomorrow evening if you agree os-prober-efi
> could help solve that
I doubt it, but I will ask upstream.

(In reply to Barry Jackson from comment #49)
> (In reply to Thomas Backlund from comment #45)

> 
> I did of course re-boot immediately after upgrade to check it was still
> booting with legacy. I then 'urpme grub2'  and rebooted again - no issues.

Just to be sure I re-tested by removing grub2 immediately after upgrade before re-booting.
Still no problem - boots with grub legacy without issue.

For reference I used Mageia-4.1-LiveCD-KDE4-en-i586-CD.iso in VBox.
I fully updated it, cloned it, booted the clone, upgraded it to to Cauldron by switching media and urpmi --auto-update, removed grub2 and rebooted.

(In reply to Nikita Krupenko from comment #29)

Please test efibootmgr-0.11.0 from updates_testing - it should fix some of the issues regarding leading zeros and failing -O option messages etc.

Thanks,
Barry

(In reply to Barry Jackson from comment #52)

> 
> Please test efibootmgr-0.11.0 from updates_testing - it should fix some of
> the issues regarding leading zeros and failing -O option messages etc.


Just for the record:

2014:10:21:22:31< barjac> marja: Ah good - I'll see if I can get 0.11.0 built

2014:10:21:22:39< barjac> marja: It's in the queue

2014:10:21:23:43< marja> barjac: "-n" works well, now (both with and without leading zeros). I've also tried "-O" and "-o" again, they still work fine, too (and no difference with and without zeros when creating a new boot order)

(my comment was compared to the 0.10.0 package I tested earlier)



Of course we won't know whether it fixes this bug, too, because we don't know of a working way to reproduce it. However, upstream fixed more bugs since 0.9.0 than just those we noticed, so there is a good chance :-)

@ Nikita

0.11.0 didn't get freeze-pushed, yet, according to the changelog ml.

 There is more chance it'll be pushed (so that it'll be in 5beta1 or 2), if you confirm it's OK

Installed efibootmgr-0.11.0-1.mga5.

1. Check current boot order:
# efibootmgr
BootCurrent: 0001
Timeout: 3 seconds
BootOrder: 0002,0001
Boot0001* mageia
Boot0002* Windows Boot Manager

2. Delete boot order:
# efibootmgr -O
BootCurrent: 0001
Timeout: 3 seconds
Boot0001* mageia
Boot0002* Windows Boot Manager

3. Set Mageia first in boot order:
# efibootmgr -o 1,2
BootCurrent: 0001
Timeout: 3 seconds
BootOrder: 0001,0002
Boot0001* mageia
Boot0002* Windows Boot Manager

But when I reboot, Windows still boots by default. When I boot into Mageia, I see the same as in (1), i.e. changes has not been actually saved.

(In reply to Nikita Krupenko from comment #54)
> Installed efibootmgr-0.11.0-1.mga5.

<snip>
> 
> But when I reboot, Windows still boots by default. When I boot into Mageia,
> I see the same as in (1), i.e. changes has not been actually saved.

or something overrides the changes :-(

is it any better with 

boot -n 1

do you get the Mageia bootloader, then?

(In reply to Marja van Waes from comment #55)
> is it any better with 
> 
> boot -n 1
> 
> do you get the Mageia bootloader, then?

Yes, it works.
 
> or something overrides the changes :-(

I found this order in EFI control utility. I changed order there and Mageia now boots first. Seems it really overrides settings made by efibootmgr.

I'm a fool

@ Nikita

after setting (again) the boot order to 0001,0002 and rebooting but going into the BIOS (or how is that called on EFI systems), what is the boot order you see there?

oops, I hadn't seen Nikita's comment

where did you find that EFI control utility?

(In reply to Marja van Waes from comment #58)
> oops, I hadn't seen Nikita's comment
> 
> where did you find that EFI control utility?

Formerly it has been called BIOS )

> after setting (again) the boot order to 0001,0002 and rebooting but going into the BIOS (or how is that called on EFI systems), what is the boot order you see there?

I see the same boot order, that was before using efibootmgr. It does not matters, what boot order I set with efibootmgr. After reboot this would be reseted to setting in BIOS (EFI control utility).

(In reply to Marja van Waes from comment #48)
> @ barjac
> 
> I'll file a separate bug report tomorrow evening if you agree os-prober-efi
> could help solve that

I spoke to upstream (grub2) and os-prober-efi is not integrated at all with grub2 so since it seems dead I think it's best ignored.

(In reply to Nikita Krupenko from comment #54)
> Installed efibootmgr-0.11.0-1.mga5.
> 
> 1. Check current boot order:
> # efibootmgr
> BootCurrent: 0001
> Timeout: 3 seconds
> BootOrder: 0002,0001
> Boot0001* mageia
> Boot0002* Windows Boot Manager
> 
> 2. Delete boot order:
> # efibootmgr -O
> BootCurrent: 0001
> Timeout: 3 seconds
> Boot0001* mageia
> Boot0002* Windows Boot Manager
> 
> 3. Set Mageia first in boot order:
> # efibootmgr -o 1,2
> BootCurrent: 0001
> Timeout: 3 seconds
> BootOrder: 0001,0002
> Boot0001* mageia
> Boot0002* Windows Boot Manager
> 
> But when I reboot, Windows still boots by default. When I boot into Mageia,
> I see the same as in (1), i.e. changes has not been actually saved.

I reported this upstream (efibootmgr).
https://github.com/vathpela/efibootmgr/issues/19

Please comment there if there is anything you can add.

Apparently updating grub2-efi can make part of the boot order get lost, too.

After updating to grub2-efi-2.02-0.git9752.9.mga5.x86_64.rpm
the last two items in my boot order list (of 5 items) were lost.

Unfortunately, Mageia was one of them (I have 2 USB options and DVD first, in case I want to install or rescue from a DVD or USB key)

(In reply to Marja van Waes from comment #62)
> Apparently updating grub2-efi can make part of the boot order get lost, too.

filed bug 14779 for that

I should probably have added attachment 5788 [details] of bug 14779 here instead of there.

It's the output of playing with efibootmgr commands and getting the "efibootmgr: Could not add entry to BootOrder: File exists" error.

Unexpected was, that when letting "efibootmgr -b 0012 -B" run when 0012 exists, but it is _not_ in the BootOrder, that made _0011_ get removed from the BootOrder instead.

(In reply to Marja van Waes from comment #64)
>
> Unexpected was, that when letting "efibootmgr -b 0012 -B" run when 0012
> exists, but it is _not_ in the BootOrder, that made _0011_ get removed from
> the BootOrder instead.

yep, thats a efibootmgr bug

(In reply to Thomas Backlund from comment #65)
> (In reply to Marja van Waes from comment #64)
> >
> > Unexpected was, that when letting "efibootmgr -b 0012 -B" run when 0012
> > exists, but it is _not_ in the BootOrder, that made _0011_ get removed from
> > the BootOrder instead.
> 
> yep, thats a efibootmgr bug

Couldn't reproduce that today.

I filed https://github.com/rhinstaller/efibootmgr/issues/24
because of bug 15498
Am not sure it caused this bug too, though

See Also: (none) => https://github.com/rhinstaller/efibootmgr/issues/24

is it possible, as a workaround, to let efibootmgr run 
efibootmgr -O
(to delete the BootOrder)
and then 
efibootmgr -c -d /dev/sda -p <ESP partition number> -w -L mageia -l \EFI\mageia\grubx64.efi 

after it gets updated, so that Mageia will always be in the BootOrder again?

I'll test if someone pushes that workaround or a better workaround or fix to cauldron core/updates_testing

Barjac pushed efibootmgr-0.11.0-4.mga5.x86_64.rpm to cauldron core/updates_testing

Please test it and check right after updating it whether anything undesired happened to your BootOrder and whether rebooting into Mageia still works.

Please then test running "grub2-install" and check BootOrder list and rebooting, too.

Thanks :-)

We have that efibootmgr-0.11.0-5.mga5 in cauldron core/release since some time, and no one reported hitting this bug again, so closing

Status: NEW => RESOLVED
Resolution: (none) => FIXED