Page MenuHomeFreeBSD

hier.7: move ESP mountpoint to /efi (from /boot/efi)
Needs ReviewPublic

Authored by emaste on Feb 20 2021, 12:14 AM.
Referenced Files
Unknown Object (File)
Sat, Sep 16, 6:18 PM
Unknown Object (File)
Wed, Sep 13, 11:24 PM
Unknown Object (File)
Aug 15 2023, 12:36 PM
Unknown Object (File)
Aug 14 2023, 7:17 AM
Unknown Object (File)
May 21 2023, 2:40 AM
Unknown Object (File)
Mar 23 2023, 4:09 AM
Unknown Object (File)
Feb 26 2023, 9:27 PM
Unknown Object (File)
Feb 15 2023, 6:25 AM



Some Linux distros/projects moved from /boot/efi to /efi, with one argument being that /boot might be a separately mounted file system.

Using /efi as the ESP mount point means that we can avoid requiring /boot to be mounted.

Linux references:
Arch Linux

Diff Detail

Lint Skipped
Tests Skipped

Event Timeline

emaste updated this revision to Diff 84314.
emaste created this revision.

Update the other locations

Still a lot of linux that uses /boot/efi... we don't have /boot as separate. It could be, but nobody has done that in the last 20 years since that argument was first articulated. Efi was proffered at the time, but there is really no way to mount the ESP as /boot anyway.

We had a conversation to get to /boot/efi 2 years ago. We should go to market with that.

Just to be pedantic: We actually *do* have /boot as separate on some systems (e.g. recent powerpc64), but those systems are mutually exclusive with EFI systems. I have a mild preference /boot/efi, but it doesn't really matter much so long as we pick something -- the status quo is it not being mounted *at all*, so reliability of mounting or whatever is obviously a second-order issue.

rgrimes added a subscriber: rgrimes.

I personally prefer /efi, as I consider /boot to belong to FreeBSD and contain the FreeBSD specific boot code. EFI is a platform specific set of boot code and belongs to the system board, and though it may contain freeBSD specific code it may also contain OTHER code, especially in a multiboot environment.

If it happens to align us with Linux, all the more reason to have it at /efi.

This revision is now accepted and ready to land.Mar 3 2021, 12:45 PM
This revision now requires review to proceed.Mar 3 2021, 2:17 PM

This patch looks good to me from a technical point of view. I have no opinion on /boot/efi vs. /efi, so won't comment on the ultimate merits of the change, but you're welcome to include a "Reviewed by:" from me if this goes in.

Maybe a seperate pass over this code to try and clean up the fact that we have used the string "/efi" many places such that it should probably become some type of #define or derived from the system make file values so that any changes to this value can be done in one place and one place only and all things using it are fixed.

I thought about this a little, and I have a concern. What happens if there is a mounted /boot/efi full of files and the cleanups are run? Is there *any* risk that this could cause loss of data? If not then this is fine, but if this might cause *any* loss we should procede with great caution on nuking any /boot/efi directory/contents.


Since we are touching this line I would really like to see mkdir -> install -d with full explicity owner/group/modes here.


The values are clearly defined here, we should be using them in ALL mkdir's translated to install -d in any place that ${EFIDIR} is used.


Anyway for this to reach into the make variables?


Same here, can we use ${EFIDIR} some how?