Does what you see in the grub2 menu agree with the output of os-prober on that machine? And if not does os-prober find all systems?

os-prober sees the other Cauldron and Windows, so everything it should see:

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

I don't think I can boot into Windows from the grub2 menu, don't even remember whether there is currently an option in the grub2 menu for it (I don't use windows), but I'll reboot and check

There is an option for Windows in the grub2 menu, but it gives an error, it can't find /EFI/Microsoft/Boot/bootmgr.efi (if I remember correctly)

The Mageia path for both bootmgr.efi and bootmgfw.efi is:
/boot/EFI/EFI/Microsoft/Boot/bootm*.efi

However, I don't see how this can be related to what happened in the EFI-BIOS and efibootmgr boot order (well, in fact, I don't see how grub2-efi could change anything there, either!)

I assume that this was using grub2-efi-2.02-0.git9752.8.mga5 (i.e. up to date) before the update to grub2-efi-2.02-0.git9752.9.mga5?
Does /var/log/grub2_post.log exist and if so what does it say? (check the file time too)
grub2-efi (on update) should have re-installed grub to the device that is listed in /boot/grub2/drakboot.conf, or if that did not exist, exit with a warning. This still needs work depending on how efi is to implemented, but that is what happens currently.

(In reply to Barry Jackson from comment #4)
> I assume that this was using grub2-efi-2.02-0.git9752.8.mga5 (i.e. up to
> date) before the update to grub2-efi-2.02-0.git9752.9.mga5?

Yes :-)

I should have seen the part about efibootmgr when grub2-efi was installed, though:
 
      3/6: grub2-efi             warning: /etc/default/grub created as /etc/default/grub.rpmnew
############################################################################################
Installing for x86_64-efi platform.
efibootmgr: Could not add entry to BootOrder: File exists
Installation finished. No error reported.
Installing grub2 to /dev/sda
Installing for x86_64-efi platform.
efibootmgr: Could not add entry to BootOrder: File exists
Installation finished. No error reported.


and, after the old grub2-efi was removed:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-desktop
Found initrd image: /boot/initrd-desktop.img
Found linux image: /boot/vmlinuz-3.18.0-desktop-1.mga5
Found initrd image: /boot/initrd-3.18.0-desktop-1.mga5.img
< a lot more lines about older linux and initrd images.>
Found Mageia 5 (5) on /dev/sda11
/usr/sbin/grub2-probe: error: cannot find a GRUB drive for Microsoft/Boot/bootmgfw.efi.  Check your device.map.
Found Windows Boot Manager on Microsoft/Boot/bootmgfw.efi
done

> Does /var/log/grub2_post.log exist and if so what does it say? (check the
> file time too)

The file time is correct. It only says:

Installing grub2 to /dev/sda

> grub2-efi (on update) should have re-installed grub to the device that is
> listed in /boot/grub2/drakboot.conf,
That says boot=/dev/sda

However, efi-booting Mageia is initiated from /boot/EFI/EFI/mageia/grubx64.efi
That file has the correct time stamp, too.

Do you by any chance know with which command grub2-efi tries to add an entry to the BootOrder? 

Was maybe "efibootmgr -c" used? If so, with which further options and variables?

I don't dare to try now whether "efibootmgr -c" can delete part of the BootOrder, because I just discovered a deep scratch on my supergrub2 disk. I'm not sure I'll find time today to burn a new one and then test.

Created attachment 5703 [details]
efibootmgr part of grub2-2.00-mga-git-9752.patch

Upstream asked which efivar version was used, and whether efivarfs was mounted correctly

[marja@DenkBlok3Cauldron5a1 ~]$ rpm -qa | grep efivar
lib64efivar0-0.11-4.mga5
[marja@DenkBlok3Cauldron5a1 ~]$ mount | grep efivarfs
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
[marja@DenkBlok3Cauldron5a1 ~]$

lib64efivar0-0.11-4.mga5 was installed on October 15th, so long before this bug was filed.

Attaching the lines from grub2-2.00-mga-git-9752.patch about efibootmgr, I don't understand yet which values to use for the variables in the efibootmgr commands in that patch, so haven't yet tried to reproduce this bug

Lost Mageia from boot menu on grub2-efi update too.
Strange thing, efibootmgr -v says, that I have two windows entries:

BootCurrent: 0001
Timeout: 3 seconds
BootOrder: 0000,0001
Boot0000* Windows Boot Manager  HD(2,c8800,96000,87e6552a-0f01-4a4c-970f-9e06a8745f88)File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
Boot0001* 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
Boot0002* Windows Boot Manager  HD(2,c8800,96000,87e6552a-0f01-4a4c-970f-9e06a8745f88)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...o................

(In reply to Marja van Waes from comment #6)
> Created attachment 5703 [details]
> efibootmgr part of grub2-2.00-mga-git-9752.patch
> 

I didn't add the efibootmgr lines that started with "-" instead of "+"

because they seemed irrelavant... grep didn't show the matching lines in the upstream tarball. 

A good night's rest makes me aware I should have unpacked it, first ;-)

Will do so asap

OK, now remembered to unpack the upstream tarball and looked again.

The only lines with efibootmgr commands I could find, are in 
grub-2.00/util/grub-install.in 

That is a section that starts on line 830
with, starting on line 840:
# Delete old entries from the same distributor.
       (then an efibootmgr command)
and, starting on 868:
# Add a new entry for the image we just created. <... more comment>
        (then some commands and ending with another efibootmgr command)

The efibootmgr grub2-2.00-mga-git-9752.patch removes this entire section. 

So it seems OK to only look at the lines that patch added in return - see attachment 5703 [details] -.

To reproduce this bug, I should maybe try something like (my EFI partition is on sda2 and my Mageia efibootmgr entry is Boot0012):

efibootmgr -b 0012 -B

efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l <correct value here>

??

I don't know yet which value to enter for -l
Only can't imagine the default (\\elilo.efi) is correct, elilo sounds like LILO, not like GRUB2-EFI

Created attachment 5714 [details]
updates install log of when grub2-efi-2.02-0.git9752.10.mga5 was installed.

I updated my system earlier this evening, grub2-efi-2.02-0.git9752.10.mga5 was among the updates. Again Mageia (and windows) disappeared from the BootOrder.

Attaching the install logs (there's a lot of debug info in them, like:
Dec 16 18:56:27 DenkBlok3Cauldron5a1_EFI logger[17583]: 05efi: debug: /dev/sda2 is a FAT32 partition
Dec 16 18:56:27 DenkBlok3Cauldron5a1_EFI logger[17583]: 05efi: debug: /dev/sda2 partition scheme is gpt
Dec 16 18:56:27 DenkBlok3Cauldron5a1_EFI logger[17583]: 05efi: debug: /dev/sda2 partition type is c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Dec 16 18:56:27 DenkBlok3Cauldron5a1_EFI logger[17583]: 05efi: debug: running subtest /usr/lib/os-probes/mounted/efi/10elilo
Dec 16 18:56:27 DenkBlok3Cauldron5a1_EFI logger[17583]: 05efi: debug: running subtest /usr/lib/os-probes/mounted/efi/20microsoft
Dec 16 18:56:27 DenkBlok3Cauldron5a1_EFI logger[17583]: 20microsoft: result: Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows
etc. )

I still want to try to reproduce this bug by using the exact efibootmgr commands that are in the grub2-2.00-mga-git-9752.patch

However, I still don't understand what string to use for "efifile_path":

 efifile_path = xasprintf ("\\EFI\\%s\\%s",
                                 efi_distributor,
                                 efi_file);

And I'm no longer sure that the used value for "efi_distributor" is "mageia", because:

efi_distributor = bootloader_id;

and, taking the rest of the code into account

bootloader_id="$(echo "$GRUB_DISTRIBUTOR" | tr 'A-Z' 'a-z' | cut -d' ' -f1)"

However, I can't find where "GRUB_DISTRIBUTOR" is defined (of course I bet it is "Mageia" ;-) ).

That I can't find it doesn't mean it isn't there!!

Setting to "release blocker", because if users can't log into Mageia after a grub2-efi update, the problem can't be fixed with an update!

Priority: High => release_blocker

Sorry for the delay, I was afraid to end up with a system with an emtpy boot order list, even in the EFI-BIOS :-þ

Anyway, now tried the commands as I think grub2-efi gives them:

efibootmgr -b 0012 -B
did remove Mageia from the BootOrder, and from the complete efibootmgr list, too
(but windows is still in both lists, so I didn't give the exact command as grub2-efi gave it)

efibootmgr -c -d /dev/sda -p 2 -w -L mageia
(I left out "-l" and its value, because still don't know which value to use)

[root@DenkBlok3Cauldron5a1_EFI marja]# efibootmgr -c -d /dev/sda -p 2 -w -L mageia
efibootmgr: Could not add entry to BootOrder: File exists                             
[root@DenkBlok3Cauldron5a1_EFI marja]# 

Now, Mageia is added to the efibootmgr list, but is *not* added to the BootOrder. The error is exactly the same as I got when updating grub2-efi:

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

> 
> I should have seen the part about efibootmgr when grub2-efi was installed,
> though:
>  
>       3/6: grub2-efi             warning: /etc/default/grub created as
> /etc/default/grub.rpmnew
> #############################################################################
> ###############
> Installing for x86_64-efi platform.
> efibootmgr: Could not add entry to BootOrder: File exists
> Installation finished. No error reported.
> Installing grub2 to /dev/sda
> Installing for x86_64-efi platform.
> efibootmgr: Could not add entry to BootOrder: File exists
> Installation finished. No error reported.
> 
> 

*If* I did not make a mistake, then either the following commands in grub2-2.00-mga-git-9752.patch are wrong, or efibootmgr is broken:

+  if (!verbosity)
+    grub_util_exec ((const char * []){ "efibootmgr", "-q",
+         "-c", "-d", efidir_disk,
+         "-p", efidir_part_str, "-w",
+         "-L", efi_distributor, "-l", 
+         efifile_path, NULL });
+  else
+    grub_util_exec ((const char * []){ "efibootmgr",
+         "-c", "-d", efidir_disk,
+         "-p", efidir_part_str, "-w",
+         "-L", efi_distributor, "-l", 
+         efifile_path, NULL });
+  free (efidir_part_str);
+}

Created attachment 5773 [details]
the efibootmgr commands as I ran them for comment 13, + their output

For the sake of clarity, attaching the commands as I ran them for comment 13 + for how I restored my BootOrder, + the matching output for each of the commands

Ignore the extra whitespace in the attachment, that wasn't there before C&P'ing from my konsole

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

> 
> efibootmgr -b 0012 -B
> 
> efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l <correct value here>
> 
> ??
> 
> I don't know yet which value to enter for -l
> Only can't imagine the default (\\elilo.efi) is correct, elilo sounds like
> LILO, not like GRUB2-EFI

The correct call would be:

efibootmgr -c -d /dev/sda -p 2 -w -L mageia2 -l \EFI\mageia\grubx64.efi

Now efibootmgr has gained some safety checks that introduces new issues

Another bad bug is our grub2 packaging doing "sysadmin" stuff in %post,
which is bad, especially for efi setups ...

I will start cleaning this up and try to integrate it better

Created attachment 5787 [details]
test the commands again

(In reply to Thomas Backlund from comment #16)
> (In reply to Marja van Waes from comment #10)
> 
> > 
> > efibootmgr -b 0012 -B
> > 
> > efibootmgr -c -d /dev/sda -p 2 -w -L mageia -l <correct value here>
> > 
> > ??
> > 
> > I don't know yet which value to enter for -l
> > Only can't imagine the default (\\elilo.efi) is correct, elilo sounds like
> > LILO, not like GRUB2-EFI
> 
> The correct call would be:
> 
> efibootmgr -c -d /dev/sda -p 2 -w -L mageia2 -l \EFI\mageia\grubx64.efi
> 
> Now efibootmgr has gained some safety checks that introduces new issues
> 
> Another bad bug is our grub2 packaging doing "sysadmin" stuff in %post,
> which is bad, especially for efi setups ...
> 
> I will start cleaning this up and try to integrate it better

Thanks :-)

Todays grub2-efi update caused no problems here, the boot order remained exactly what is was, so for me it is fixed with grub2-efi-2.02-0.git9752.12.mga5.x86_64.rpm :-D 

About the attachment: 

I've played with the correct call you gave (first with "-L mageia2", later with "-L mageia"), both still give the "efibootmgr: Could not add entry to BootOrder: File exists" error.

Letting "efibootmgr -b 0012 -B" run when 0012 exists, but when it is already missing from the BootOrder, made _0011_ get removed from the BootOrder instead. 
Maybe that explains why Windows was (when I hit this bug) removed from the BootOrder, too. I saw the error message twice when originally updating grub2-efi (see comment 5 ), maybe both commands were run twice?

Attachment 5773 is obsolete: 0 => 1

Nikita, can you confirm it is fixed with 
grub2-efi-2.02-0.git9752.12.mga5.x86_64.rpm ?

sorry, that is not the correct attachment :-(
looking for the correct one, now

Created attachment 5788 [details]
test the command again

now attaching the correct file

(In reply to Marja van Waes from comment #17)
> About the attachment: 
> 
> I've played with the correct call you gave (first with "-L mageia2", later
> with "-L mageia"), both still give the "efibootmgr: Could not add entry to
> BootOrder: File exists" error.
> 
> Letting "efibootmgr -b 0012 -B" run when 0012 exists, but when it is already
> missing from the BootOrder, made _0011_ get removed from the BootOrder
> instead. 
> Maybe that explains why Windows was (when I hit this bug) removed from the
> BootOrder, too. I saw the error message twice when originally updating
> grub2-efi (see comment 5 ), maybe both commands were run twice?

Attachment 5787 is obsolete: 0 => 1

(In reply to Marja van Waes from comment #18)
> Nikita, can you confirm it is fixed with 
> grub2-efi-2.02-0.git9752.12.mga5.x86_64.rpm ?

After update, no one entry disapperared, so I can cofirm.

Though I still see no graphical menu for grub, that has been broken IIRC in 10.mga5 or 9.mga5, but this may be different issue.

(In reply to Nikita Krupenko from comment #21)
> (In reply to Marja van Waes from comment #18)
> > Nikita, can you confirm it is fixed with 
> > grub2-efi-2.02-0.git9752.12.mga5.x86_64.rpm ?
> 
> After update, no one entry disapperared, so I can cofirm.
> 
> Though I still see no graphical menu for grub, that has been broken IIRC in
> 10.mga5 or 9.mga5, but this may be different issue.

Yeah, indeed.

Anyway, closing this bug as fixed

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