Regression Can't determine since when but our packaged Virtualbox can't boot EFI ISO (M7, M8) Even, with a media in CDROM tray, with a EFI VM, it can't load EFI Install. I did can do it earlier in 2020. Instead, it loads an EFI shell. Note that with is reproduced with all M8 kernels host. The issue seems in virtualbox itself. $ uname -r 5.10.8-desktop-2.mga8 $ rpm -qa -last | grep virtualbox virtualbox-kernel-desktop-latest-6.1.16-50.mga8.x86_64 Mon Jan 18 14:50:32 2021 virtualbox-kernel-5.10.8-desktop-2.mga8-6.1.16-50.mga8.x86_64 Mon Jan 18 14:50:32 2021 virtualbox-kernel-5.10.7-desktop-1.mga8-6.1.16-46.mga8.x86_64 Wed Jan 13 17:55:33 2021 virtualbox-6.1.16-15.mga8.x86_64 Tue Jan 12 14:13:36 2021 virtualbox-kernel-5.10.6-desktop-1.mga8-6.1.16-45.mga8.x86_64 Tue Jan 12 14:13:25 2021 virtualbox-kernel-5.10.5-desktop-2.mga8-6.1.16-37.mga8.x86_64 Sat Jan 9 11:51:12 2021 Assigning to package maintainer.
Really assigning. CC'd QA and ISO producer.
CC: tmb => davidwhodgins, mageia, wilcal.intAssignee: thierry.vignaud => tmb
It was a regression in VBox 6.1.14: https://www.virtualbox.org/ticket/19910 I attached a patch that fixes it 3 weeks ago, but there's been no response from the VBox maintainers as yet.
Due to buggy efi support, for the last 6 years or so, efi testing has only been done on real hardware. Using efi under vb has not been supported by Mageia. While it may work, it's unlikely.
Not so Dave. I test every ISO build with EFI in VirtualBox. Up until this regression, there has been no problem with it (apart from the EFI NVRAM forgetting its contents when you power down the VM, which is easily worked around). I also used VirtualBox to test and debug EFI boot for the new memory test program that's on the ISOs.
(In reply to Martin Whitaker from comment #2) > It was a regression in VBox 6.1.14: > > https://www.virtualbox.org/ticket/19910 > > I attached a patch that fixes it 3 weeks ago, but there's been no response > from the VBox maintainers as yet. That's not so surprising as their public source trees have stalled on: 12/18/2020... Eithers they are running low on developers as they are hiring more or they are running in release testing mode planning to splash out 6.2... I guess we could merge that patch if it helps testing.
It's a bit more complicated than merging the patch. Normally the EFI firmware is a pre-built binary blob, and rebuilding it doesn't work out of the box. I can probably reconstruct what I did to get it to build if you want. Currently I'm using a local build, so it's not critical for me.
CC: (none) => fri
Hello, A user reported me than with virtualbox 6.1.18 r1142142, he can start Kubuntu 20.10, but not Mageia ISO in EFI mode. He uses this method for demonstration purposes before students. I think there is still two problems: virtualbox looking only in EFI/boot, thus doesn't find EFI/mageia. And another one point by Martin.
CC: (none) => yves.brungard_mageia
(In reply to papoteur from comment #7) > I think there is still two problems: > virtualbox looking only in EFI/boot, thus doesn't find EFI/mageia.VirtualBox 6.1.18 saves and restores the contents of the EFI NVRAM when you power down and power up the VM, so you can now install the bootloader in /EFI/mageia instead of /EFI/BOOT. The annoying thing is that having done this, VBox then ignores the boot order specified in the VM settings, so you can no longer easily override it and boot from a CDROM/ISO instead (the workaround is to delete the VM .nvram file). > And another one point by Martin. Still no response from the VBox devs on that bug.
According the cited bug the problem should be fixed in virtualbox 6.1.34. As we have this version since April 2022 in MGA8 this should be fixed. Can we close this bug as FIXED or is there still something not working?
Just tested booting the Mageia 8 Xfce 64-bit Live ISO with our packaged VirtualBox 6.1.34 and can confirm it's fixed.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED