Mount ESP on newly-installed systems
ClosedPublic
Actions

Authored by nwhitehorn on Feb 23 2021, 3:09 PM.

Details

Reviewers

emaste
imp
allanjude
tsoome

Commits

rG3dbc2213dacb: Mount the EFI system partition (ESP) on newly-installed systems and VM
rG611d83116a6c: Mount the EFI system partition (ESP) on newly-installed systems and VM
rG0b7472b3d8d2: Mount the EFI system partition (ESP) on newly-installed systems.

Summary

This patch mounts the ESP (on UFS installations, see notes below) at /boot/efi. It also dramatically simplifies the creation/detection and initialization of the ESP by leveraging the parts of the partition editor that detect pre-existing boot partitions.

After the patch, the ESP behaves as follows:

The partition editor will reuse an existing ESP, otherwise will make one and format as FAT32
The ESP will be mounted at /boot/efi (though see D28814)
The bootconfig script is now only responsible for setting up the loader on a mounted ESP rather than formatting/mounting/etc. It detects an EFI system by seeing if there is a /boot/efi directory on the installed system.
For redundant ZFS-root systems, space is reserved for an ESP on all root-pool disks, but only one is initialized and mounted.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

nwhitehorn requested review of this revision.Feb 23 2021, 3:09 PM

nwhitehorn created this revision.

There is this thing....

root@beastie:~# zpool status
  pool: rpool
 state: ONLINE
  scan: resilvered 1,68T in 0 days 10:10:07 with 0 errors on Fri Oct 25 05:05:34 2019
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            c3t0d0  ONLINE       0     0     0
            c3t1d0  ONLINE       0     0     0
            c3t3d0  ONLINE       0     0     0
            c3t4d0  ONLINE       0     0     0

errors: No known data errors
root@beastie:~#

I have 4 disks in my boot pool, every single one is bootable and can be selected from firmware; which one should be used to mount ESP?:)

In D28897#646717, @tsoome wrote:

There is this thing....

root@beastie:~# zpool status
  pool: rpool
 state: ONLINE
  scan: resilvered 1,68T in 0 days 10:10:07 with 0 errors on Fri Oct 25 05:05:34 2019
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            c3t0d0  ONLINE       0     0     0
            c3t1d0  ONLINE       0     0     0
            c3t3d0  ONLINE       0     0     0
            c3t4d0  ONLINE       0     0     0

errors: No known data errors
root@beastie:~#

I have 4 disks in my boot pool, every single one is bootable and can be selected from firmware; which one should be used to mount ESP?:)

The installer doesn't create things like this, so this is out of scope for this patch. :).

However, the real answer is 'the one that booted the system' which requires either some hairy parsing of efibootmgr output, or some support from geom. The ESP is always the system you booted from. However, with chain loading, that can get hairy and the general convention is the last one from what I've seen. In general, the BIOS selects a drive to boot from, sets BootCurrent and from that we can know where we came from.

It's not the universe of all possible ESPs, but the one we booted from. Redundant boot scenarios are tricky in general, and extreme care should be taken when updating them because you can't know what the user wants absent more information...

This revision is now accepted and ready to land.Feb 23 2021, 3:21 PM

I'd really like this in 13.0 if possible.

@imp any thoughts on the gmirror solution for ZFS? I think it solves 95% of the update issues and shouldn't be too bad to implement.

tsoome accepted this revision.Feb 23 2021, 4:00 PM

In D28897#646728, @nwhitehorn wrote:

@imp any thoughts on the gmirror solution for ZFS? I think it solves 95% of the update issues and shouldn't be too bad to implement.

As stated elsewhere, gmirror is horrible for pre-boot environments. The UEFI Firmware doesn't know about mirrors, so will gladly boot off a broken mirror shard that's out of date.

Having multiple ESPs is already a special snowflake environment. How best to deal with it and keep it up to date is tricky, not least because some of the decisions necessary for that are often BIOS specific as the details in how things are searched matter, and certain failure scenarios have to be dealt with carefully (like what if one of the drives fails read-only: the only solution there is to remove it from the boot order, or force it to be last).

With proper warnings, it may be OK, but I'd never ever use it. Again.