OpenMandriva Lx version:
Lx 3 installed from ISO’s 1298 or 1314 and fully updated.
Desktop environment (KDE, LXQT…):
KDE/Plasma5
Description of the issue (screenshots if relevant):
Installed system in VirtualBox (with EFI boot selected) boots to interactive shell. So far this has happened on 2 computers.
Relevant informations (hardware involved, software version, logs or output…):
VirtualBox from OM repos version 5.1.22, of course correct Extension Pack is installed.
Now pay attention to what I’m saying here. The ISO itself will EFI boot. It is the installed system in VirtualBox that boots to the interactive shell. I certainly can post VBox logs if that would help. Which logs to post as there are 4 for each installed system? What I mean is do I post VBox.log? VBox.log.x?
I don’t yet have a sense of whether this is an OpenMandriva problem with something not being written or is it a VirtualBox bug?
There is a work around to get system to boot. What you have to do is edit (actually create) ‘startup.nsh’ and point the interactive shell to ‘\EFI\openmandriva\grubx64.efi’. If anyone else has this issue I can post the exact procedure.
Hi Ben,
I’ve looked into this and it’s almost certainly a Calamares issue.
First a bit of background. The live image boots because the efi boot file is called BOOTX64.EFI the system bios looks for this file when in UEFI mode and uses it to boot the system if it is present. If you explore the INSTALLED boot partion from the uefi shell command line (Typically type FS0: and then use ‘ls’ and ‘cd’ to explore the directories) you’ll see that the installed EFI name is not BOOTX64.EFI but grubx64.efi and grub efi. If you do “cp grubx64.efi BOOTX64.EFI” you will find that VB will then boot the sytem automatically without the use of startup.nsh.
There has been a change in the way that Calamares writes the bootloader when it installs it as it’s no longer creating a BOOTX64.EFI file hence the failure in VB. Two names can co-exist in the EFI boot directory by virtue of the utility ‘efibootmgr’ which on a real system can be used to set the default boot name to something other than the default. Since the efi variables are saved in non-volatile ram a normal system will use the specifically named boot entry. VB does not save the efi variables as it have no non-volatile ram so it always goes to the default entry BOOTX64.EFI if it exists or if it doesn’t it starts the UEFI shell until you create a bootfile. I will try and find out what and why it has been changed.
As a side not for me the ‘Install OpenMnadriva’ entry has stopped working again too.
bets,
Colin
Thanks for your time on this Colin. And you are correct about copying (or renaming) the file fixing (workaround fix) problem. It is interesting that in system installed on hardware the file ‘/boot/efi/EFI/boot/bootx64.efi’ exists but somehow in a VirtualBox install it doesn’t seem to get written.
If one is in the Interactive Shell in VirtualBox:
> fs0:
> \EFI\openmandriva\grubx64
exit and now system should boot normally.
When one is in the installed (VirtualBox) system in order to permenently correct this issue simply open Konsole and as root:
