Bug 23785 - M6.1 UEFI install does not boot in a Vbox client
Summary: M6.1 UEFI install does not boot in a Vbox client
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-30 19:05 CET by William Kenney
Modified: 2018-11-01 03:29 CET (History)
1 user (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
UEFI boot error window in a Vbox client (39.57 KB, image/png)
2018-10-30 19:06 CET, William Kenney
Details

Description William Kenney 2018-10-30 19:05:05 CET
Description of problem:

Help me understand how to set up a M6.1 Vbox client UEFI install.
I have tried both netinstall and the latest:

Mageia-6.1-LiveDVD-Plasma-x86_64-DVD.iso

and the end result is the same. See attachment

After the install using the MCC I can see the FAT partition.
All seems to go per:

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

during the install.

But shutting down the client then restarting it results in a hung
boot at an error page. See attached uefi_install_fail_org.png
No keyboard action seems to allow the boot to proceed.

Yes, I have checked the Enable EFI (special OSes only) in
System/Motherboard

Up till now I have used the legacy boot and am trying to get up
to speed on UEFI so that I can use that boot on my M7 installs.

Thanks
Comment 1 William Kenney 2018-10-30 19:06:22 CET
Created attachment 10439 [details]
UEFI boot error window in a Vbox client
Comment 2 Martin Whitaker 2018-10-31 00:46:55 CET
There is a flaw in the VirtualBox implementation of the UEFI non-volatile RAM - it is in fact volatile! So the setting that tells it which EFI image to boot from gets lost when you power off the client. It does however survive when you reset the client.

There are two routes to fixing this:

1. The easy way. Run the installer from the Live desktop. Once the install is complete, reboot. It should immediately show the GRUB menu that allows you to boot the newly installed system. When you reach the desktop, open a terminal window and execute the following commands:

  mkdir /boot/EFI/EFI/BOOT
  cp /boot/EFI/EFI/mageia/grubx64.efi /boot/EFI/EFI/BOOT/bootx64.efi

You should then be able to boot into the installed system after a shutdown.

2. The harder way. After completing an installation, shut down the client. On restart, immediately press the F12 key (there's only a small window of opportunity to do this, so you have to be quick). This will take you into the BIOS menu. Select "Boot Maintenance Manager", then "Boot From File". You'll then see a very verbose description of your EFI system partition. Select that, then "<EFI>", then "<mageia>", then "grubx64.efi". That should take you to the GRUB menu, after which proceed as above to fix the problem and prevent you going through this rigmarole every time.

If you have trouble pressing F12 in time, try temporarily reducing the processor execution cap in the VirtualBox settings.

In Mageia 7 there will be an even easier fix. I have added support for the rEFInd boot manager, and included the option to install it in /EFI/BOOT. There's real hardware out there that has this problem too!

CC: (none) => mageia

Comment 3 William Kenney 2018-10-31 18:43:46 CET
Thanks Martin. The "easy way" did in fact work for me using the netinstall iso
I will try the Live-DVD later today

Upon reboot I did in fact have to remove the Mageia-6.1-netinstall-x86_64.iso
from the Vbox client boot sequence chain and make the virtual HD as boot
priority #1. Otherwise the entire install process would start all over again.
Comment 4 William Kenney 2018-11-01 03:29:55 CET
Install from desktop using: Mageia-6.1-LiveDVD-Plasma-x86_64-DVD.iso

Then modifying boot using the "easy way" also works just fine.
Setting this bug to resolved.

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


Note You need to log in before you can comment on or make changes to this bug.