Bug 22395

(In reply to Christoph Eser from comment #0)

> grub2-install: Fehler: »/boot/EFI/EFI/tmp/grubx64.efi« kann nicht geöffnet

Did you create the /boot/EFI/EFI/tmp/grubx64.efi path, Christopher, or did drakboot do that? The path amazes me, because /boot/EFI is the ISP, that should remain untouched, since you selected the "Do not touch ESP or MBR" option.

Btw,you're running a very old kernel, the one with which Mageia 6 was released! Maybe, on an earlier occasion when you used drakboot, this screen http://doc.mageia.org/mcc/6/en/content/images/drakboot3.png proposed that kernel as "Default", and you didn't notice? There's a bug report about drakboot proposing the oldest available kernel, instead of the option that'll always use the newest one, see bug#22274

CC: (none) => mageiatools, marja11
Summary: drakboot crashed: Installing grub configuration with the option "don't change MBR" => drakboot crashed: Installing grub configuration with the option "don't change MBR" (grub2-install: /boot/EFI/EFI/tmp/grubx64.efi can't be opened, file or directory not found)
Keywords: (none) => NEEDINFO
Assignee: bugsquad => zen25000
Source RPM: drakxtools-17.88.1-1.mga6 => grub2

(In reply to Marja van Waes from comment #1)
> (In reply to Christoph Eser from comment #0)
> 
> > grub2-install: Fehler: »/boot/EFI/EFI/tmp/grubx64.efi« kann nicht geöffnet
> 
> Did you create the /boot/EFI/EFI/tmp/grubx64.efi path, Christopher, or did
> drakboot do that? The path amazes me, because /boot/EFI is the ISP, that
> should remain untouched, since you selected the "Do not touch ESP or MBR"
> option.
> 
>

That is correct - there is no actual mechanism in grub2 to not 'touch' the ESP at all. This is a workaround to not break the existing nvram setup.(i.e. not overwrite an existing /boot/EFI/EFI/mageia/grubx64.efi).
So in practice it does write to the ESP. There is a bug about this but nothing can be done until grub2 provides a way to update itself without creating a grub64.efi.

What caused this error I don't know - I always use that option as I use a dedicated primary grub2 installation on a separate partition and I never saw this. If this is 'file not found', maybe it's referring to the path up to 'tmp' which it maybe could not create for some reason?

(In reply to Marja van Waes from comment #1)
> (In reply to Christoph Eser from comment #0)
> 
> > grub2-install: Fehler: »/boot/EFI/EFI/tmp/grubx64.efi« kann nicht geöffnet
> 
> Did you create the /boot/EFI/EFI/tmp/grubx64.efi path, Christopher, or did
> drakboot do that? The path amazes me, because /boot/EFI is the ISP, that
> should remain untouched, since you selected the "Do not touch ESP or MBR"
> option.
> 
> Btw,you're running a very old kernel, the one with which Mageia 6 was
> released! Maybe, on an earlier occasion when you used drakboot, this screen
> http://doc.mageia.org/mcc/6/en/content/images/drakboot3.png proposed that
> kernel as "Default", and you didn't notice? There's a bug report about
> drakboot proposing the oldest available kernel, instead of the option
> that'll always use the newest one, see bug#22274

I didn't create the boot/EFI/EFI/tmp/grubx64.efi path
The screen you mentioned I didn't see before.
After starting drakeboot out of the control center I got the message that no bootmanager was found and a new configuration will be created.
The crash happens on creating the bootmanager
After the crash the grub menu now list all kernels with are installed.
(Before starting drakeboot an the crash grub menu only has the item kernel 4.9.35-desktop-1.mga6)
Starting drakeboot furthermore reports "no bootmgr found a configuration will be created".

Background information:
My EFI system has two different partions with two different Mageia 6 instances.
One of it is a Mageia 6 system which was upgraded from Mageia 5
(For this system drakboot also reports that no bootmgr is found, but I didn't try to generate one)

The system where drakboot crashed was initial installed as Mageia 6. During installation it occupied the EFI bootmgr entry of the before existing Mageia installation which was upgraded from Mageia 5.  
After installation of this second instance I created a new NVRAM entry to make the original installation which was upgraded from Mageia 5 to 6 bootable again.

Is there an EFI System Partition on each drive? The new Mageia 6 install should have used the existing one on the other drive.

Why did you need to alter NVRAM? The Mageia 6 install should have used os-prober to add the older install on the other drive to the new grub2 menu without needing any manual changes.


/OT
Unrelated to this bug specifically, but I would consider doing this if you have multiple UEFI OSs on different drives:
https://wiki.mageia.org/en/User_talk:Barjac

(In reply to Barry Jackson from comment #4)
> Is there an EFI System Partition on each drive? The new Mageia 6 install
> should have used the existing one on the other drive.
> 
> Why did you need to alter NVRAM? The Mageia 6 install should have used
> os-prober to add the older install on the other drive to the new grub2 menu
> without needing any manual changes.
> 
> 
> /OT
> Unrelated to this bug specifically, but I would consider doing this if you
> have multiple UEFI OSs on different drives:
> https://wiki.mageia.org/en/User_talk:Barjac

There is only one drive but different partitions. The new Mageia 6 installation added the old Mageia installation to its grub menu so that it would be bootable from the new Mageia 6 installation.
Here the reason why I manually created a NVRAM entry for the old installation:
The old installation ist my primary Mageia system. I did an additionally installation of Mageia 6 only for testing reasons because the update from Mageia 5 to Mageia 6 caused ugly folder icons (see https://forums.mageia.org/de/viewtopic.php?f=7&t=3210)

OK thanks - I misunderstood.

Can you show the outputs of:

su

cat /boot/grub2/install.sh

for both installations please, indicating which is which (new/old)

Also how did you upgrade the old system? (classic dvd+net/urpmi/net-install.iso)

------------------------
To explain a little...
In your set-up where the old installation is intended to control the boot menu, the contents of /boot/grub2/install.sh in the old system should be:

grub2-install

In the new Mageia 6 installation the contents of /boot/grub2/install.sh should be:

grub2-install --bootloader-id=tmp --no-nvram

If those are correct then running:

su

/boot/grub2/install.sh

from within either system should not produce any errors, and the boot menu should not be affected by the new Mageia 6.

To include new kernels in the menu for the new Mageia 6 you will need to run: 

update-grub2

from the old system.

/OT
When using a master grub2 (as produced by my script mentioned earlier) this interaction between systems is avoided, as both systems are set to not affect the nvram and both use their own boot menus which appear after the initial system selection in the master boot menu which is never touched by either system.

Keywords: (none) => UPSTREAM

(In reply to Barry Jackson from comment #6)
> OK thanks - I misunderstood.
> 
> Can you show the outputs of:
> 
> su
> 
> cat /boot/grub2/install.sh
> 
> for both installations please, indicating which is which (new/old)
> 
> Also how did you upgrade the old system? (classic
> dvd+net/urpmi/net-install.iso)
> 
> ------------------------
> To explain a little...
> In your set-up where the old installation is intended to control the boot
> menu, the contents of /boot/grub2/install.sh in the old system should be:
> 
> grub2-install
> 
> In the new Mageia 6 installation the contents of /boot/grub2/install.sh
> should be:
> 
> grub2-install --bootloader-id=tmp --no-nvram
> 
> If those are correct then running:
> 
> su
> 
> /boot/grub2/install.sh
> 
> from within either system should not produce any errors, and the boot menu
> should not be affected by the new Mageia 6.
> 
> To include new kernels in the menu for the new Mageia 6 you will need to
> run: 
> 
> update-grub2
> 
> from the old system.
> 
> /OT
> When using a master grub2 (as produced by my script mentioned earlier) this
> interaction between systems is avoided, as both systems are set to not
> affect the nvram and both use their own boot menus which appear after the
> initial system selection in the master boot menu which is never touched by
> either system.

The content of /boot/grub2/install.sh is as you assumed

old system: grub2-install
new system: grub2-install --bootloader-id=tmp --no-nvram

The update of the old system was made by using dvd

On the new system I run /boot/grub2/install.sh an get the error message
boot/EFI/EFI/tmp/grubx64.efi not found
The content of /boot/grub2/grub.cfg seems to be ok

My efi partition has 
- on directory for the new installation (directory mageia) with grubx64.efi
- another directory for the old installation (directory mageiorg) also with grubx64.efi

There are corresponding NVRAM entries
mageia pointing to the new installatin
mageiaorg pointing to the old installation which is my primary one

On bootup I can decide which installation to boot by EFI-Menu of bios
(Standard is mageiorg defined by efibootmgr --bootorder)

What would happen if I call grub2-install on the old installation (mageiaorg)?

(In reply to Christoph Eser from comment #7)
> 
> The content of /boot/grub2/install.sh is as you assumed
> 
> old system: grub2-install
> new system: grub2-install --bootloader-id=tmp --no-nvram
> 
> The update of the old system was made by using dvd
> 
> On the new system I run /boot/grub2/install.sh an get the error message
> boot/EFI/EFI/tmp/grubx64.efi not found
> The content of /boot/grub2/grub.cfg seems to be ok
> 
> My efi partition has 
> - on directory for the new installation (directory mageia) with grubx64.efi
> - another directory for the old installation (directory mageiorg) also with
> grubx64.efi

I suspect that manually changing the ESP has confused grub2.

> 
> There are corresponding NVRAM entries
> mageia pointing to the new installatin

This should not exist if it was installed with --bootloader-id=tmp
I would change this path to /boot/EFI/EFI/tmp/grubx64.efi 

> mageiaorg pointing to the old installation which is my primary one

This should be called mageia and should be the only mageia named entry.
/boot/EFI/EFI/mageia/grubx64.efi

> 
> On bootup I can decide which installation to boot by EFI-Menu of bios
> (Standard is mageiorg defined by efibootmgr --bootorder)

That should not be necessary as both systems are in the grub2 menu.

> 
> What would happen if I call grub2-install on the old installation
> (mageiaorg)?

Use /boot/grub2/install.sh rather than grub2-install it's safer as you don't want to run grub2-install without arguments on the new system accidentally.
Follow this with update-grub2.

It should then boot using the boot menu for your 'primary' system.

With the above changes you should be able to run /boot/grub2/install.sh from the new system (to test only, it's not necessary) without errors and not affect the primary system boot in any way.

Barry

(In reply to Barry Jackson from comment #8)
> (In reply to Christoph Eser from comment #7)
> > 
> > The content of /boot/grub2/install.sh is as you assumed
> > 
> > old system: grub2-install
> > new system: grub2-install --bootloader-id=tmp --no-nvram
> > 
> > The update of the old system was made by using dvd
> > 
> > On the new system I run /boot/grub2/install.sh an get the error message
> > boot/EFI/EFI/tmp/grubx64.efi not found
> > The content of /boot/grub2/grub.cfg seems to be ok
> > 
> > My efi partition has 
> > - on directory for the new installation (directory mageia) with grubx64.efi
> > - another directory for the old installation (directory mageiorg) also with
> > grubx64.efi
> 
> I suspect that manually changing the ESP has confused grub2.
> 
> > 
> > There are corresponding NVRAM entries
> > mageia pointing to the new installatin
> 
> This should not exist if it was installed with --bootloader-id=tmp
> I would change this path to /boot/EFI/EFI/tmp/grubx64.efi 
> 
> > mageiaorg pointing to the old installation which is my primary one
> 
> This should be called mageia and should be the only mageia named entry.
> /boot/EFI/EFI/mageia/grubx64.efi
> 
> > 
> > On bootup I can decide which installation to boot by EFI-Menu of bios
> > (Standard is mageiorg defined by efibootmgr --bootorder)
> 
> That should not be necessary as both systems are in the grub2 menu.
> 
> > 
> > What would happen if I call grub2-install on the old installation
> > (mageiaorg)?
> 
> Use /boot/grub2/install.sh rather than grub2-install it's safer as you don't
> want to run grub2-install without arguments on the new system accidentally.
> Follow this with update-grub2.
> 
> It should then boot using the boot menu for your 'primary' system.
> 
> With the above changes you should be able to run /boot/grub2/install.sh from
> the new system (to test only, it's not necessary) without errors and not
> affect the primary system boot in any way.
> 
> Barry

Now I renamed the NVRAM entry of my old and primary installation to "mageia" and started
/boot/grub2/install.sh

I got the error message /boot/EFI/EFI/mageia/grubx64.efi could not be opened or
directory or file does not exist.
That's right because my UEFI partion has the directory structure
/boot/EFI/efi/mageia (efi in lowercase letters) which was never manually changed.

Did you ever have Windows installed?
Mageia has only ever used /boot/EFI/EFI/

(In reply to Barry Jackson from comment #10)
> Did you ever have Windows installed?
> Mageia has only ever used /boot/EFI/EFI/

My machine had Windows 7 preinstalled. 
The original installation of Mageia 5 was done as described in the Mageia documentation. (After installation of Mageia 5 I also upgraded Windows 7 to Windows 10.)
The later parallel clean installation of Mageia 6 also ran through without problems.

Ah, so you always had the lower case in the ESP which explains the original error message I suspect.

I am not sure how we handle re-use of existing Windows ESP partitions as I don't have any windows machines.

@Thierry
Any suggestions? Looking back in ML I saw your comment about the mountpoint being upper case but I do not understand how the root dir of the ESP (/efi in this case) is affected by that.

Christopher,
Do you see the path as /boot/EFI/efi/ from both systems or only the older one?

I just installed Win8.1 in a clean VM and then installed Mageia 6 alongside it and from Mageia /boot looks like:

/boot
├── config-4.14.13-desktop-1.mga6
├── dracut
├── EFI
│   └── EFI
│       ├── Boot
│       │   └── bootx64.efi
│       ├── mageia
│       │   └── grubx64.efi
│       └── Microsoft
│           └── Boot
│               ├── BCD
│               ├── BCD.LOG
│               ├── BCD.LOG1
│               ├── BCD.LOG2
│               ├── bg-BG
│               │   ├── bootmgfw.efi.mui
│               │   └── bootmgr.efi.mui
│               ├── bootmgfw.efi
------------snip-----------------

Created attachment 9914 [details]
Structure of the EFI-partition of my machine (I used a live system to mount the whole partition to "efipartion")

(In reply to Barry Jackson from comment #13)
> Christopher,
> Do you see the path as /boot/EFI/efi/ from both systems or only the older
> one?
> 
> I just installed Win8.1 in a clean VM and then installed Mageia 6 alongside
> it and from Mageia /boot looks like:
> 
> /boot
> ├── config-4.14.13-desktop-1.mga6
> ├── dracut
> ├── EFI
> │   └── EFI
> │       ├── Boot
> │       │   └── bootx64.efi
> │       ├── mageia
> │       │   └── grubx64.efi
> │       └── Microsoft
> │           └── Boot
> │               ├── BCD
> │               ├── BCD.LOG
> │               ├── BCD.LOG1
> │               ├── BCD.LOG2
> │               ├── bg-BG
> │               │   ├── bootmgfw.efi.mui
> │               │   └── bootmgr.efi.mui
> │               ├── bootmgfw.efi
> ------------snip-----------------

The path is the same from the old an the new system. 
In comment 14 you find a screenshot of the structure of the whole EFI partition.

I have no idea how this happened but I would be tempted to boot into Mageia and edit the directory from efi to EFI.

It's not needed after boot so this can be done from a running system.

Then run as root /boot/grub2/install.sh from both systems.

This may fix things but will not explain exactly how you got here.

(In reply to Barry Jackson from comment #16)
> I have no idea how this happened but I would be tempted to boot into Mageia
> and edit the directory from efi to EFI.
> 
> It's not needed after boot so this can be done from a running system.
> 
> Then run as root /boot/grub2/install.sh from both systems.
> 
> This may fix things but will not explain exactly how you got here.

I understand that the entry isn't necessary after boot.
I am afraid to rename the directory because it is the root directory of the EFI partition and I don't know how the BIOS of my machine works and how it finds the entries which can be booted.
The directory name efi always seemed to be in lowercase letters on this machine.
I have the fear that the system will not start after changing the directory name.

Christoph

I understand your caution.

If you make a Live Mageia 6 USB stick and check that you can boot from it, you could make the change by mounting the ESP in the live session.

In the event that it did cause a boot problem, you could revert the change the same way.

As the ESP is on a vfat partition I suspect it will not break boot, but I will test changing it in my VM from EFI to efi later and report back.

I renamed /boot/EFI to /boot/efi in my VM rebooted and all was well,

/boot
├── config-4.14.13-desktop-1.mga6
├── dracut
├── EFI
│   ├── efi
│   │   ├── Boot
│   │   │   └── bootx64.efi
│   │   ├── mageia
│   │   │   └── grubx64.efi
│   │   └── Microsoft
│   │       └── Boot
│   │           ├── BCD
│   │           ├── BCD.Backup.0001
│   │           ├── BCD.LOG
│   │           ├── BCD.LOG1
│   │           ├── BCD.LOG2
│   │           ├── bg-BG
│   │           │   ├── bootmgfw.efi.mui
│   │           │   └── bootmgr.efi.mui
-----snip-------------

... so I see no problem in you doing the reverse.

Do something like this:

su

# Back-up efi in root:

cd /boot/EFI
mkdir /efibak
cp -r efi/* /efibak/

# Unmount ESP:

umount /boot/efi

# Remount ESP on temp folder:

mkdir /tmpefi
# Get the device assignment of the ESP:
blkid | grep "EFI system partition"|cut -d: -f1
mount /dev/sdxy /tmpefi

# Rename in two steps as FAT sees upper/lower case as the same directory:
cd /tmpefi
mv efi tmp
mv tmp EFI

# See if it looks OK:
tree

# Unmount the ESP from temp folder and delete temp folder:
cd ..
umount /tmpefi
rm /tmpefi -rf

# Fingers crossed ;)

reboot

Now try running /boot/grub2/install.sh followed by update-grub from both systems.

# Unmount ESP:

umount /boot/efi

That should of course be:

# Unmount ESP:

umount /boot/EFI

Sorry :/

@Thierry

The issue here seems to be that /boot/EFI/EFI/tmp is hardcoded in drakboot.

It needs to check the path for "efi" or "EFI" and use the appropriate one, since AFAICT either will work correctly from a grub2 P.O.V.

Especially if in future we switch to /boot/EFI/efi/ for compatibility with other distros.

Assignee: zen25000 => bugsquad
Source RPM: grub2 => drakboot

(In reply to Barry Jackson from comment #20)
> # Unmount ESP:
> 
> umount /boot/efi
> 
> That should of course be:
> 
> # Unmount ESP:
> 
> umount /boot/EFI
> 
> Sorry :/

(In reply to Barry Jackson from comment #19)
> I renamed /boot/EFI to /boot/efi in my VM rebooted and all was well,
> 
> /boot
> ├── config-4.14.13-desktop-1.mga6
> ├── dracut
> ├── EFI
> │   ├── efi
> │   │   ├── Boot
> │   │   │   └── bootx64.efi
> │   │   ├── mageia
> │   │   │   └── grubx64.efi
> │   │   └── Microsoft
> │   │       └── Boot
> │   │           ├── BCD
> │   │           ├── BCD.Backup.0001
> │   │           ├── BCD.LOG
> │   │           ├── BCD.LOG1
> │   │           ├── BCD.LOG2
> │   │           ├── bg-BG
> │   │           │   ├── bootmgfw.efi.mui
> │   │           │   └── bootmgr.efi.mui
> -----snip-------------
> 
> ... so I see no problem in you doing the reverse.
> 
> Do something like this:
> 
> su
> 
> # Back-up efi in root:
> 
> cd /boot/EFI
> mkdir /efibak
> cp -r efi/* /efibak/
> 
> # Unmount ESP:
> 
> umount /boot/efi
> 
> # Remount ESP on temp folder:
> 
> mkdir /tmpefi
> # Get the device assignment of the ESP:
> blkid | grep "EFI system partition"|cut -d: -f1
> mount /dev/sdxy /tmpefi
> 
> # Rename in two steps as FAT sees upper/lower case as the same directory:
> cd /tmpefi
> mv efi tmp
> mv tmp EFI
> 
> # See if it looks OK:
> tree
> 
> # Unmount the ESP from temp folder and delete temp folder:
> cd ..
> umount /tmpefi
> rm /tmpefi -rf
> 
> # Fingers crossed ;)
> 
> reboot
> 
> Now try running /boot/grub2/install.sh followed by update-grub from both
> systems.


I renamed the  directory "efi" to "EFI". (It was not necessary to umount/mount the partition.) The only thing I had to do was to rename "efi" to something else and after this to rename it to "EFI"
Then I ran /boot/grub2/install.sh followed by update-grub from both systems and now all is fine.

I found out that the files of the EFI (GPT formated) partition are not handled case sensitive by my hardware. For testing purposes I renamed grubx64.efi to Grubx64.efi and the corresponding installation could still be booted.

By the way I found a very good explanation what happens booting with EFI firmware. If you are interested here the URL: 
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/

According to a remark in this description Fedora seems to mount the EFI partition to /boot/efi (lowercase)

I think your suggestion to Thierry to check for "EFI" or "efi" and use the appropriate one is very helpful.

At last I thank you very much for your support.

Christoph

(In reply to Barry Jackson from comment #21)
> @Thierry
> 
> The issue here seems to be that /boot/EFI/EFI/tmp is hardcoded in drakboot.
> 
> It needs to check the path for "efi" or "EFI" and use the appropriate one,
> since AFAICT either will work correctly from a grub2 P.O.V.
> 
> Especially if in future we switch to /boot/EFI/efi/ for compatibility with
> other distros.

CC'ing tmb and martinw

If no one replies, then it might be better to discuss this on dev ml.

@ Barry

The UPSTREAM keyword is no longer needed, is it?

CC: (none) => mageia, tmb
Keywords: NEEDINFO, UPSTREAM => (none)
Assignee: bugsquad => mageiatools

(In reply to Barry Jackson from comment #21)
> The issue here seems to be that /boot/EFI/EFI/tmp is hardcoded in drakboot.
> 
> It needs to check the path for "efi" or "EFI" and use the appropriate one,
> since AFAICT either will work correctly from a grub2 P.O.V.
> 
> Especially if in future we switch to /boot/EFI/efi/ for compatibility with
> other distros.

It's the other way round.

The first part of the path is the mount point in the Linux file system. Mageia chooses to use /boot/EFI. All other distros I know about use /boot/efi.

The last part of the path is the directory name in the ESP. The UEFI specification (http://www.uefi.org/specifications) states this should be "EFI". But because the ESP uses the FAT32 file format, non-Unix software will normally perform a case-insensitive match when locating files. I guess we should try to do so to.

P.S. There's also an explanation of the EFI boot process on the Mageia Wiki:

  https://wiki.mageia.org/en/About_EFI_UEFI

which in turn links to Adam W.'s explanation that Christoph found.

(In reply to Martin Whitaker from comment #24)
> (In reply to Barry Jackson from comment #21)
> 
> It's the other way round.
> 
Yes of course - my typo

CC: (none) => zen25000

@ Christoph
This bug is now nearly 2 years old. Is it still an issue?
* Martin rightly pointed out the ESP mount point is /boot/efi/ in most Linux distributions, Mageia's /boot/EFI/ is a confusing exception;
* Within the ESP, the top level directory is always EFI/ (or EFI\, depending on context).
It looks as if what you wanted to do was have >1 Mageia installed. This is (for some of us) quite normal, and there are different ways to achieve it, as described at the end of https://wiki.mageia.org/en/About_EFI_UEFI "Multiple instances of a distribution".
- The most recently installed system will show all other instances in its Grub2 menu.
- Make your own separation in NVRAM & EFI\ as described therein.
- Install & use rEFInd instead:
-- With separate \EFI\<name> sub-directories, whose different grubx64.efi will be found & offered
-- With nothing: rEFInd now finds & can directly load installed systems. You have to configure the bootloader to use it. Once there, you will never look back.
Up to you to get rEFInd booted first...
The Wiki would have saved you (& respondants) a lot of time. [Although I fear it is wrong about grub2-install/efibootmgr; to correct].

CC: (none) => lewyssmith

I get it fixed for my machine. (See my comment above from 2018-01-21 19:30:48 CET )
I don't know whether it is still an issue.
I think you can close it.

Christoph

Thanks for you feed back.
Thus closing

CC: (none) => yves.brungard_mageia
Status: NEW => RESOLVED
Resolution: (none) => FIXED

(In reply to Barry Jackson from comment #21)
> @Thierry
> 
> The issue here seems to be that /boot/EFI/EFI/tmp is hardcoded in drakboot.
> 
> It needs to check the path for "efi" or "EFI" and use the appropriate one,
> since AFAICT either will work correctly from a grub2 P.O.V.
> 
> Especially if in future we switch to /boot/EFI/efi/ for compatibility with
> other distros.

No it's not. There's no mention of "/boot/EFI/EFI/tmp" at all.
We only add --bootloader-id=tmp 
As confirmed by your checks in https://bugs.mageia.org/show_bug.cgi?id=22395#c7

We could however rename efi to EFI…

Created attachment 11565 [details]
rename /boot/EFI/efi as /boot/EFI/EFI if needed

This patches should fix such dualboot issues (harmless for Windows)