From Mageia wiki
Jump to: navigation, search
Drakconf multiflag.png
Other languages

Deutsch ; English ;

This page is also available in german

Please note!
An easy way to repair the EFI bootloader in Mageia 5, even for people who are afraid of the command line, is to do an upgrade install with a classical (not Live) 64bit DVD.

Mageia disappeared from the efibootmgr BootOrder list

See also Bug 14140: boot order settings lost when updating efibootmgr

The above bug got fixed. However, just in case anything like that happens again, here are some methods to be able to boot into Mageia again:

For Mageia 5: the rescue function of the non-Live 64bit Mageia dvd

If you choose to rescue instead of to install Mageia, you'll get a text interface (command line), from which you can reinstall the Mageia EFI-bootloader. After that, you can reboot and everything should work as before

Boot with SuperGrub2 disk

SuperGrub2 disk

This method works great when you can boot from CD or DVD, so don't forget to put that first in the boot order list in your BIOS. If you don't know how to get into your BIOS, then please search the internet or ask in the forums for help

USB support for this method is still experimental.

There are several ways to boot into Mageia with this disk, choose e.g.: "boot manually....", then "operating systems" and then arrow down till you see the newest vmlinuz on the correct partition (The same with "single" appended is probably rescue mode).

Boot with rEFInd


This one has proven to work well after putting it on a USB stick to boot from. It might work just as well from DVD.

Repairing the efibootmgr BootOrder

After using SuperGrub2 disk or rEFInd to boot into Mageia, first become root and then:

  • to see the full list of available boot entries, run efibootmgr
    • You'll see the hexadecimal number of the Mageia entry, and many more entries with hexadecimal numbers like 0003, 000C or 0012.
  • to delete the current boot order, run efibootmgr -O
  • to create a new boot order with Mageia first, run efibootmgr -o <number of Mageia entry>,<number of next desired entry>,<number of next desired entry>
    • for instance, if Mageia's entry in efibootmgr has number 000B and some other entries you want to be in the BootOrder have 0006, 000F and 0011, this command would be: efibootmgr -o 000B,0006,000F,0011

reboot and see that you can boot nicely into Mageia again

But Mageia isn't in the efibootmgr list!

In that case, first run:

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

after changing "/dev/sda" and "-p 1" (partition number 1) to the correct values, if needed.

Boot Drops to UEFI Shell (in VirtualBox)

When running Mageia under UEFI in a VirtualBox VM, booting can suddenly fail, dropping to a UEFI Shell. This is possibly a VBox bug, however all is not lost! At the shell prompt type:


The prompt will change to indicate that you are in fs0, now:


Look for a directory called "EFI". (The "EFI" is in blue text on black which is virtually invisible on some monitors). If you have a CD in the drive that will be fs0, so you will need to repeat the above replacing fs0: with fs1: etc. until 'ls' finds "EFI". Now at the prompt type:

cd EFI/mageia

That will boot into the grub2 menu.

Having to do this repeatedly (during boot testing for example) becomes tedious, so a fix is to create an EFI shell script as: /boot/EFI/startup.nsh The script is a plain text file e.g.:

if not exist EFI then
cd EFI/mageia

With that installed (which is adequate in most cases), when the EFI shell appears, the script will launch after a few seconds unless you hit ESC to stop it. If you hit ENTER as soon as the shell appears the script will launch instantly, saving a lot of repetitive typing and time.

Boot displays "No Bootable Device" when rebooting after a fresh install of Mageia

Some machines (notably some Acer laptops) have a buggy UEFI BIOS that requires the UEFI boot file to be set as "trusted" even when Secure Boot is disabled. The problem is compounded by the fact that the options to set files as trusted are not available when secure boot is disabled, and as most how-to texts start by ensuring that secure boot is disabled, it's far from clear how to do this. If you are hit by this issue:

  • Enter the machine BIOS (usually F2) during early boot.
  • Set a password for secure boot. DO NOT FORGET IT.
  • Enable Secure Boot.
  • Now continue from step 35 onwards in this "Ask Ubuntu" reply. [1]

Obviously select the "mageia" folder where ubuntu is mentioned in the above. You should then be able to boot into Mageia with secure boot enabled. You can then disable secure boot and set the secure boot password back to blank and the machine will continue to boot into Mageia.