I have been trying to compile my own grub2 boot code files (core.img and bootx64.efi) recently.
To do this, I needed to set up a VM with Ubuntu x64 in UEFI-mode.
Easy right?
Err.... no!
1. Create a new VM in Virtual Box with a 16GB virtual HDD
2. Assign the ubuntu-16.04-desktop-amd64.iso as a virtual DVD
3. Tick the System - Enable EFI checkbox and ensure at least 64Mb of graphics memory for UEFI.
4. Boot from the DVD, choose Install, Auto option - allow it to copy the files to the virtual HDD after partitioning it - reboot.
I just pressed ENTER and nothing happened!
So I used the VM controls to disconnect the virtual CD and then pressed ENTER - nada!
In the end, I used the 'reset' option in the VM to reset the virtual machine and it rebooted to Ubuntu.
I did some Googling and found a workaround: It said to type this into the EFI console:
fs0:
cd EFI
cd ubuntu
grubx64.efi
This worked, but I had to do this every time that I powered off the VM!
However, I noticed that there was no \EFI\boot\bootx64.efi file present in the EFI partition. This meant that Ubuntu must be relying on efibootmgr and the non-volatile memory in the UEFI-BIOS to know that it needed to load \EFI\ubuntu\grubx64.efi to boot.
Now VBox does not have any persistent UEFI non-volatile storage, so as soon as the VM was powered down, this UEFI setting was lost.
As the default UEFI boot file is always \EFI\boot\bootx64.efi (for a 64-bit UEFI system), I did this to fix it:
fs0:
mkdir /EFI/boot
cp /EFI/ubuntu/* /EFI/boot
cd EFI
cd boot
cp grubx64.efi bootx64.efi
Probably the only file needed was /EFI/boot/bootx64.efi, but I copied all the files just in case as there were only a few of them.
This fixed the problem and now it boots correctly!
I would have thought that if the Ubuntu installer detected that a /EFI/boot/bootx64.efi was not present, it would have put one there as a fallback, but apparently not!
To do this, I needed to set up a VM with Ubuntu x64 in UEFI-mode.
Easy right?
Err.... no!
Method
Pretty straight forward...1. Create a new VM in Virtual Box with a 16GB virtual HDD
2. Assign the ubuntu-16.04-desktop-amd64.iso as a virtual DVD
3. Tick the System - Enable EFI checkbox and ensure at least 64Mb of graphics memory for UEFI.
4. Boot from the DVD, choose Install, Auto option - allow it to copy the files to the virtual HDD after partitioning it - reboot.
Problem 1 (remove the CD!)
The install completed and then prompted me to remove the 'CD' and press ENTER.I just pressed ENTER and nothing happened!
So I used the VM controls to disconnect the virtual CD and then pressed ENTER - nada!
In the end, I used the 'reset' option in the VM to reset the virtual machine and it rebooted to Ubuntu.
Problem 2 (no boot!)
Perfect! It rebooted and I was into Ubuntu. It all worked (I used the 'Save Machine State' option to quit the VM).... or so I thought until I shut down the VM ('power off') and later re-booted to the VM hard disk.... it just loaded the UEFI shell!I did some Googling and found a workaround: It said to type this into the EFI console:
fs0:
cd EFI
cd ubuntu
grubx64.efi
This worked, but I had to do this every time that I powered off the VM!
However, I noticed that there was no \EFI\boot\bootx64.efi file present in the EFI partition. This meant that Ubuntu must be relying on efibootmgr and the non-volatile memory in the UEFI-BIOS to know that it needed to load \EFI\ubuntu\grubx64.efi to boot.
Now VBox does not have any persistent UEFI non-volatile storage, so as soon as the VM was powered down, this UEFI setting was lost.
As the default UEFI boot file is always \EFI\boot\bootx64.efi (for a 64-bit UEFI system), I did this to fix it:
fs0:
mkdir /EFI/boot
cp /EFI/ubuntu/* /EFI/boot
cd EFI
cd boot
cp grubx64.efi bootx64.efi
Probably the only file needed was /EFI/boot/bootx64.efi, but I copied all the files just in case as there were only a few of them.
This fixed the problem and now it boots correctly!
I would have thought that if the Ubuntu installer detected that a /EFI/boot/bootx64.efi was not present, it would have put one there as a fallback, but apparently not!
No comments:
Post a Comment