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



## JoseMR (May 23, 2022)

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:

```
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:

```
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:

```
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


----------



## grahamperrin@ (May 23, 2022)

FreeBSD bug 255318 – handbook: Document how to update the bootloader



JoseMR said:


> … the VirtualBox UEFI/Entry got messed-up …



You can use efibootmgr(8). See, for example <https://forums.freebsd.org/posts/563833>


----------



## JoseMR (May 24, 2022)

Hi grahamperrin, thanks for pointing out the bug and for sharing the useful links regarding VirtualBox/EFI and the `efibootmgr`.
Regards


----------



## JoseMR (May 24, 2022)

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

```
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:*


Spoiler



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


----------

