FreeBSD 13.x EFI(ESP) installation behavior/bug?

JoseMR

JoseMR

Hello, I've tried to search about this issue with little to none relevant results, really sorry if this has been discussed elsewhere.

Since I've been testing/playing with the FreeBSD 13.x branch on VM(VirtualBox), I had some issues with the EFI loader installation on mirrored Root-on-ZFS installs, according to the bsdinstall bsdinstall_log, only the first disk efi partition is being formatted and prepared as ESP.

Here is a quick overview of the mirrored boot disk layout:
Code: 
root@freebsd13vm:~ # gpart show
=>      40  33554352  ada0  GPT  (16G)
        40    532480     1  efi  (260M)
    532520      1024     2  freebsd-boot  (512K)
    533544       984        - free -  (492K)
    534528   4194304     3  freebsd-swap  (2.0G)
   4728832  28823552     4  freebsd-zfs  (14G)
  33552384      2008        - free -  (1.0M)

=>      40  33554352  ada1  GPT  (16G)
        40    532480     1  efi  (260M)
    532520      1024     2  freebsd-boot  (512K)
    533544       984        - free -  (492K)
    534528   4194304     3  freebsd-swap  (2.0G)
   4728832  28823552     4  freebsd-zfs  (14G)
  33552384      2008        - free -  (1.0M)

root@freebsd13vm:~ # fstyp /dev/ada0p1
msdosfs
root@freebsd13vm:~ # fstyp /dev/ada1p1
fstyp: /dev/ada1p1: filesystem not recognized
root@freebsd13vm:~ # df -hT /boot/efi
Filesystem   Type       Size    Used   Avail Capacity  Mounted on
/dev/ada0p1  msdosfs    260M    1.8M    258M     1%    /boot/efi

So after testing this behavior, I've noticed that removing the first disk to emulate a disk failure and boot from the remaining one(the second one), rendered the system unbootable under UEFI as expected.

Then I've restored the disk and decided to manually prepare the ESP on the second drive and retest.
Here is what I did:
Code: 
root@freebsd13vm:~ # newfs_msdos /dev/ada1p1
/dev/ada1p1: 532288 sectors in 16634 FAT16 clusters (16384 bytes/cluster)
BytesPerSec=512 SecPerClust=32 ResSectors=1 FATs=2 RootDirEnts=512 Media=0xf0 FATsecs=65 SecPerTrack=63 Heads=16 HiddenSecs=0 HugeSectors=532480
root@freebsd13vm:~ # mkdir /tmp/esp
root@freebsd13vm:~ # mount_msdosfs /dev/ada1p1 /tmp/esp
root@freebsd13vm:~ # cp -a /boot/efi/ /tmp/esp/
root@freebsd13vm:~ # umount /tmp/esp
root@freebsd13vm:~ # fstyp /dev/ada1p1
msdosfs

After the above quick solution I was able to boot UEFI from the second disk after removing the first one, however after fiddling with the disks attaching/detaching re-positioning I've noticed that the VirtualBox UEFI/Entry got messed-up and the VM was unable to boot UEFI automatically.

Then again I've noticed that the file startup.nsh was missing, then adding this file back to both of the disks efi partition(for backward compatibility) made the VM to boot from either disk under UEFI again automatically after few secs.

Here is what I did:
Code: 
root@freebsd13vm:~ # mount_msdosfs /dev/ada1p1 /tmp/esp
root@freebsd13vm:~ # echo "BOOTx64.efi" > /boot/efi/efi/boot/startup.nsh
root@freebsd13vm:~ # echo "BOOTx64.efi" > /tmp/esp/efi/boot/startup.nsh
root@freebsd13vm:~ # umount /tmp/esp

Hopefully this may help some.
Regards
 

Attachments

  • bsdinstall_log.txt
    78.8 KB · Views: 56
Hi grahamperrin, thanks for pointing out the bug and for sharing the useful links regarding VirtualBox/EFI and the efibootmgr.
Regards
 
I also have to note that I use solely Root-on-ZFS Mirror for my FreeBSD machines/VM's boot supporting both GPT-BIOS + UEFI.

However I've had some hassle when upgrading the system/zroot leading me to manually update the bootcode on the system regularly, then I created a small script to do this job and I will share here the code for reference and/or experimental purposes as this bootcode update topic seems to be regarded lately.

BSD-Bootcode-Updater
Code: 
root@mserver: ~# bootcode-update -h
Usage: bootcode-update [option]
Options:
        -d | --dryrun   Execute a dryrun test only.
        -e | --efi      Update EFI bootcode.
        -g | --gpt      Update GPT/ZFS bootcode.
        -a | --all      Update both EFI and GPT bootcode.
        -h | --help     Print this help message and exit.
        -v | --version  Print the version info and exit.


Utility working and output:
root@mserver: ~# uname -r
12.3-RELEASE-p5
root@mserver: ~# bootcode-update -a

UEFI Partition: [ ada0p1 ]
Disk Serial: [ XXX519GYXXXXXX ]
Proceed with EFI bootcode update for the following geom: [ada0p1] (Y/n)?: y
Proceeding...
=> Updating EFI bootcode on ada0p1
/boot/loader.efi -> /tmp/boot_esp/efi/boot/bootx64.efi
=> Success!


UEFI Partition: [ ada1p1 ]
Disk Serial: [ XXX817TM85A3TDXXXXXX ]
Proceed with EFI bootcode update for the following geom: [ada1p1] (Y/n)?: y
Proceeding...
=> Updating EFI bootcode on ada1p1
/boot/loader.efi -> /tmp/boot_esp/efi/boot/bootx64.efi
=> Success!


Boot Partition: [ ada0p2 ]
Disk Serial: [ XXX519GYXXXXXX ]
Pool Member: [ zroot: '/dev/ada0p4' ]
Proceed with GPT/ZFS bootcode update for the following geom: [ada0p2] (Y/n)?: y
Proceeding...
=> Updating GPT/ZFS bootcode on ada0p2
partcode written to ada0p2
bootcode written to ada0
=> Success!


Boot Partition: [ ada1p2 ]
Disk Serial: [ XXX817TM85A3TDXXXXXX ]
Pool Member: [ zroot: '/dev/ada1p4' ]
Proceed with GPT/ZFS bootcode update for the following geom: [ada1p2] (Y/n)?: y
Proceeding...
=> Updating GPT/ZFS bootcode on ada1p2
partcode written to ada1p2
bootcode written to ada1
=> Success!

I wish I could write an optimized version in C but I'm a novice in such department.
Regards
 
You must log in or register to reply here.
Back
Top