What happens if you boot into the Live USB, and, instead of changing the boot order, you only tell what to boot into next, with 

   efibootmgr -n <entry number of installed Mageia>

and then reboot while leaving the USB key inserted?

Keywords: (none) => NEEDINFO
CC: (none) => marja11, tmb, zen25000

Btw, which iso did you user to install Mageia?

(Changing version to "Cauldron" because already released isos cannot be fixed, and adding "MGA5" to the whiteboard, because that's the highest version with which this problem was seen)

Version: 5 => Cauldron
Whiteboard: (none) => (MGA5)

s/user/use/

(In reply to Marja van Waes from comment #1)
> What happens if you boot into the Live USB, and, instead of changing the
> boot order, you only tell what to boot into next, with 
> 
>    efibootmgr -n <entry number of installed Mageia>
> 
> and then reboot while leaving the USB key inserted?

Hello,
I see: 
actual boot : 0003 (EFI)
next noot: 0000 (Mageia)
I reset with leaving the Live USB key inserted
I have an traditional error message:
[0.00358...]ignorint BGRT: invalid status 0 (expected 1)
The Live USB continue and I am again en Mageia Live

(In reply to Marja van Waes from comment #2)
> Btw, which iso did you user to install Mageia?
> 
> (Changing version to "Cauldron" because already released isos cannot be
> fixed, and adding "MGA5" to the whiteboard, because that's the highest
> version with which this problem was seen)

I have made my iso by isodumper and have verified isi with md5sim and sha1sum as writtent i doc:https://wiki.mageia.org/en/Mageia_en_dual_boot_avec_Windows8_et_suivants-fr#Choix_de_l.27image_ISO

The version is 64bits because it's necessary to UEFI( my PC has Intel Pentium N3540 which is OK with 64bits. source: internet)

Partitions:
sda1 de type ext4, de taille 20Gio avec point de montage sur /
sda2 de type EFI Syst Partition de taille 100Mio avec point de montage /boot/EFI
sda3 de type Swap de taille 3.9Gio
sda4 de type ext4 de taille 441Gio avec point de montage sur /home

I see also en the first panel:
Mageia 5
noyau: 3.19.8-desktop-3.mga5
arch: 64-bit
Bureau: KDE

I don't understand 

(Changing version to "Cauldron" because already released isos cannot be
> fixed, and adding "MGA5" to the whiteboard, because that's the highest
> version with which this problem was seen)

and

s/user/use/

sorry

(In reply to Jean Pansu from comment #6)
> 
> I don't understand 
> 
> (Changing version to "Cauldron" because already released isos cannot be
> > fixed, and adding "MGA5" to the whiteboard, because that's the highest
> > version with which this problem was seen)

We can not fix bugs in Mageia 5 or earlier isos, but we want to make sure that a bug you find in Mga5 is fixed before Mga6.
Cauldron is where we fix such bugs.
> 
> and
> 
> s/user/use/

That was the correction of a typo I made in comment 2.

I wrote "user"  but that should have been "use"

I can't find whether you used a Live iso to install from, or a tradional iso (non-Live is tradional) ;-)

(In reply to Marja van Waes from comment #7)
> (In reply to Jean Pansu from comment #6)
> > 
> > I don't understand 
> > 
> > (Changing version to "Cauldron" because already released isos cannot be
> > > fixed, and adding "MGA5" to the whiteboard, because that's the highest
> > > version with which this problem was seen)
> 
> We can not fix bugs in Mageia 5 or earlier isos, but we want to make sure
> that a bug you find in Mga5 is fixed before Mga6.
> Cauldron is where we fix such bugs.
> > 
> > and
> > 
> > s/user/use/
> 
> That was the correction of a typo I made in comment 2.
> 
> I wrote "user"  but that should have been "use"
> 
> I can't find whether you used a Live iso to install from, or a tradional iso
> (non-Live is tradional) ;-)

I have a traditional Mageia 5 installed on my PC with partitions as indicated upper (comment 5). At the end of this traditional installation, I had to reboot (all was correct) but the PC never want root on installed traditional Mageia.
In the french forum "lebarhon" (http://www.mageialinux-online.org/forum/topic-22424-4.php#m215991)says me to do a Live Mageia USB. With her I can change the order boot.But the firmware seem refuse other OS than Windows.

"Lebarhon" thinks that:
"Je pense que les Public Keys sont les clés décernées par Microsoft, dans ce cas, Mageia n'en a pas, affaire terminée.
Je ne vois qu'une solution, c'est de trouver ou on peut déclarer un "UEFI file" comme étant de confiance. Il faudrait trouver une doc du Firmware de l'Akoya 6239, je n'ai rien trouvé."

"Papoteur" in the french forum has wroten today:
"Il semble que ce matériel soit surtout distribué en Allemagne. J'ai vu un fil de discussion qui décrivait des symptômes similaires, et pour lesquels il était proposé de mettre à jour le micrologiciel. Cependant c'était pour passer d'une version 6.7 à 6.13, or tu as une 7.02 (sur un forum en allemand).
Le manuel de l'ordi n'aborde pas les détails du réglage de l'UEFI.
Les discussions autour du matériel de cette marque suggéraient de faire l'installation en mode CSM, puis de revenir en UEFI, pour Ubuntu. Je ne vois pas encore de voie bonne candidate pour la résolution de la question. "

Unfortunately there is nothing we can do here...

If the efi firmware is hardcoded to use windows as default it will ignore anything that efibootmgr tries to change.

In order to get it fixed, contact the Medion hw vendor about getting a fixed uefi firmware that obeys the efi settings, thery are the only ones that can fix it.

There is some HP an Lenovo laptops out there that have the same issue...

One "workaround" is to learn what key combination triggers uefi boot selector at boot so you can select mageia efi bootloader from there...

You may be able to adopt this workaround (see final comment in the thread)

https://communities.intel.com/thread/43629

Thx Barry :-)

@ Frédéric

Do you mind creating "FOR_ERRATA" and "IN_ERRATA" keywords?

FOR_ERRATA is to track bugs that should be added to the errata.
IN_ERRATA is for bugs that have been added.

Yeah, that's going to bite us when something is added to the Mga6 errata, but also needed for the Mga7 errata :-(

Let's wait for comment from Stormi and Akien

What about FOR_ERRATA_6 and IN_ERRATA_6 ?

Keywords: NEEDINFO => (none)
CC: (none) => LpSolit, rverschelde, stormi
Whiteboard: (MGA5) => (MGA5) FOR_ERRATA_5 FOR_ERRATA_6

(In reply to Marja van Waes from comment #11)
> Do you mind creating "FOR_ERRATA" and "IN_ERRATA" keywords?

I would suggest to use a flag for that, because FOR_ERRATA and IN_ERRATA are mutually exclusive, and so keywords are not the best choice for this, IMO. A flag named "in_errata", would behave like this:

in_errata? means bugs that should be added to the errata.
in_errata+ means bugs that have been added.
in_errata- means bugs that have been proposed to be put in the errata, but have been rejected to be in the errata.

What do you think?


> Yeah, that's going to bite us when something is added to the Mga6 errata,
> but also needed for the Mga7 errata :-(

We could have in_errata6, in_errata7, etc... flags if needed.

(In reply to Barry Jackson from comment #10)
> You may be able to adopt this workaround (see final comment in the thread)
> 
> https://communities.intel.com/thread/43629

I have unsuccesfully tried it but porblem is an other

(In reply to Frédéric Buclin from comment #12)
> (In reply to Marja van Waes from comment #11)
> > Do you mind creating "FOR_ERRATA" and "IN_ERRATA" keywords?
> 
> I would suggest to use a flag for that, because FOR_ERRATA and IN_ERRATA are
> mutually exclusive, and so keywords are not the best choice for this, IMO. A
> flag named "in_errata", would behave like this:
> 
> in_errata? means bugs that should be added to the errata.
> in_errata+ means bugs that have been added.
> in_errata- means bugs that have been proposed to be put in the errata, but
> have been rejected to be in the errata.
> 
> What do you think?

You're right, a flag would be much better, and the above ones would do. Thanks :-)
> 
> 
> > Yeah, that's going to bite us when something is added to the Mga6 errata,
> > but also needed for the Mga7 errata :-(
> 
> We could have in_errata6, in_errata7, etc... flags if needed.

That would have my preference. However, I'm trying to remember why stormi was against adding the Mga release to "FOR_ERRATA" and such which we started using on the whiteboard for Mga5.

He'll remember, but is on holiday now, and mostly without internet.

(In reply to Jean Pansu from comment #13)
> (In reply to Barry Jackson from comment #10)
> > You may be able to adopt this workaround (see final comment in the thread)
> > 
> > https://communities.intel.com/thread/43629
> 
> I have unsuccesfully tried it but porblem is an other

Another issue on some hardware that may be related is this one:

https://wiki.mageia.org/en/EFI:_can_no_longer_boot_into_Mageia#Boot_displays_.22No_Bootable_Device.22_when_rebooting_after_a_fresh_install_of_Mageia

I added two remarks to the errata for Mageia 5, 

The "Please note!" here:
https://wiki.mageia.org/en/Mageia_5_Errata#UEFI_installs
and the lines at the bottom of the page, that that note links to.

However, I'm not sure it is entirely correct what I wrote. Could someone please check?

======

What should be done with this report: left open even if it's technically invalid, so that it's easier for other affected users to find it?

Whiteboard: (MGA5) FOR_ERRATA5 FOR_ERRATA6 => (MGA5) FOR_ERRATA6

Does this only affect dualboot systems?
If so, the Errata should say so.

CC: (none) => cooker

(In reply to Johnny A. Solbu from comment #17)
> Does this only affect dualboot systems?
> If so, the Errata should say so.


I hope that tmb or barjac can answer that question for all such systems. 

(Because, if someone would tell what it's like on his system, that doesn't mean that's true for all hardware with this bug)

Summary: Impossible boot on Medion Akoya E6239 (just windows 7 & 8.1 accepted) => Impossible to boot Mageia by default on some Medion, Lenovo and HP laptops (EFI firmware hardcoded to use Windows as default)

It would be interesting to remove the HD from one of these machines and replace it with a clean drive, then install Mageia.

On my HP 450G2 Probook all listed options (both BIOS and efibootmgr) for default booting of Mageia were unsuccessful. 
  Whatever was specified, it default booted Windows 10!

Finally I obtained the desired default by  executing in Windows10 the command:
  
 bcdedit /set {bootmgr} path \EFI\mageia\grubx64.efi
  
    N.B. Must use a 'Terminal (Administrator)' session.
         (No good as 'user with administrator rights')

P.S.
If you have rEFInd installed, then the command would be:

   bcdedit /set {bootmgr} path \EFI\refind\refind_x64.efi

CC: (none) => maurice

If a box insists on loading Windows, you should be able to get it load what you want (ideally rEFInd) by first making a backup copy of the Windows bootloader:
 \EFI\Microsoft\Boot\bootmgfw.efi
then *replacing* it - under the same name - with the bootloader you want.
As a second measure, do the same with the normal EFI default (when nothing else works) bootloader:
 \EFI\Boot\bootx64.efi

CC: (none) => lewyssmith

That's what I first did over a year ago when installing Mageia-5 on the HP Probook - before discovering that the Windows10 'bcd' command would make a cleaner job of it!

Having spotted this bug still open, I think *it should be closed* because:
- It is not a Mageia-specific problem
- We can do nothing about it for Windows specific hardware
- Comments 20 and 21 give solutions.
 on condition that:
Somewhere in our documentation - Release Notes? - we alert users to the potential problem, and give them these solutions.
It does not seem to me that this warrants either FOR or IN_ERRATA. It is not an error.
If somebody agrees with all this, please close the bug. (I do not want to tread on toes).

This is not a Mageia-specific problem, but a hardware one.
There are easy workarounds, the Windows 'bcd' command being the neatest. See
comment 20.
See also:
https://wiki.mageia.org/en/About_EFI_UEFI#Multi-booting_.26_EFI_Boot_Managers

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