grub4efi: cannot boot to Ubuntu ISO files to grub2 menu under VirtualBox 5
steve6375 opened this issue · 22 comments
2022-07-19 was OK and booted to grub2 menu
but later versions seem very buggy
e.g.
map /Ubuntu64.iso (0xff)
chainloader (0xff)
hangs - does not show grub2 menu - just hangs
have a try
BOOTX64.rar.txt
I tested same version as given by partnew bootx64.efi - I assume it is the same?
Still a problem - hangs on chainloader command
same
debug 3
map /_ISO/.......
have a try
map /_ISO/LINUX/Ubuntu-2xxxx.iso (0xff)
chainloader (0xff)
Can you upload an empty ISO image？
all ISOs fail to run, linux, fatdog, pmagic, windows install isos, etc,
P.S. Seems to be a new issue with new version. If I run an animation then the background wallpaper does not show.
Here is latest BOOTX64.efi - it should display moon background but it does not.
If I exit to grub4efi commandline and then press ESC then I get background
Older versions used to work - is this due to recent bugfix for splashimage/graphicsmode bug ?
P.S. I can work around this bug by adding into startup menu.lst file
pause --wait=1 > nul
then background is displayed behind menu OK.
If I use pause --wait=0 > nul then the background does not appear - so delay is needed?
Even with pause --wait=1 if I try to load a second menu or navigate the existing menu then I get a memory error
Only get memory error if animation is loaded.
Ubuntu-18.04.6-desktop-amd64.iso can be successfully started。
For animation, give me a way to reproduce it.
It seems that it does not like Virtual Box 5 (booting from USB).
I tested on a real system and it does map and run the ISO - so maybe some memory issue when running under VBox ???
However, the animation / wallpaper issue is still present on a real system and i see the memory malloc errors after navigating the menu a few times same as under VBOX.
On real system, Free_mem_start: 0x10000
on VBOX Free_mem_start: 0x0
would this cause a problem ???
error when booting from Ubuntu ISO
Please test。
BOOTX64.rar.txt
Seems to be a bit better but still problems booting under VBOX 5. Ubuntu booting from ISO erratic.
pmagic_2018_10_12.iso does not boot
Strange 0x60 device after map ??
iftitle [if exist /_ISO/LINUX/pmagic_2018_10_12.iso] Parted Magic 2018 (LIVE)\nBoot Parted Magic with Save Session option.
set ISO=/_ISO/LINUX/pmagic_2018_10_12.iso
graphicsmode -1 1024
errorcheck on
debug on
debug msg=3
map --status
map --read-only %ISO% (0xff) || map --mem %ISO% (0xff)
map --hook
map --status
root (0xff)
# add nomodeset if you get black screen on boot
# add lang=yes if you want to pick a language
kernel /pmagic/bzImage64 edd=on vga=normal iso_filename=%ISO% boot=live eject=no
initrd /pmagic/initrd.img /pmagic/fu.img /pmagic/m64.img
pause
boot
similar panic if boot on lenovo ideapad 300.
60 is the CD boot image. Start Linux and add the parameter '--old' after the ‘kernel’to give it a try.
kernel --old /pmagic/bzImage64 edd=on vga=normal iso_filename=%ISO% boot=live eject=no
--old does not help
Give this one a try。
kernel --handover /pmagic/bzImage64 edd=on vga=normal iso_filename=%ISO% boot=live eject=no
initrd /pmagic/initrd.img /pmagic/fu.img /pmagic/m64.img
BOOTX64.rar.txt
That seems to work OK (bit slow maybe?) - thanks! 👍
Will we always need to specify --handover or do you intend to make it use this by default?
It will be very awkward if we have to specify --handover for some ISOs but not for others...
This version of grub4efi seems to NOT be able to work with a1ive's wimboot though (it crashes when wimboot starts to load wim into memory). Can this be fixed too?
As a test, I tried --handover on wimboot but kernel command would not work
There is no parameter '-- handover' and supports the new UEFI loading method 'LoadFile2' for Linux.
There is a parameter '-- handover' that supports the old UEFI loading method 'EFI Handover Protocol' in Linux. This method is being abandoned since Linux 6.2.
There is a parameter '-- handover' that only supports kernel versions 0x20b and above. The old method is not supported.
it seems that partedmagic 2018 does not need the --handover parameter for this new grub4efi, it boots OK without it so not sure why you told me to use the --handover parameter as it is not needed?
Both of these work...
kernel --handover /pmagic/bzImage64 edd=on vga=normal iso_filename=%ISO% boot=live eject=no
initrd /pmagic/initrd.img /pmagic/fu.img /pmagic/m64.img
kernel /pmagic/bzImage64 edd=on vga=normal iso_filename=%ISO% boot=live eject=no
initrd /pmagic/initrd.img /pmagic/fu.img /pmagic/m64.img
If it can be started without use, it will not be used.
Many people have reported that the new version of G4e cannot start old Linux, so this parameter has been added. You can ignore this parameter.