efi)
Needs ReviewPublic
Actions

Authored by emaste on Feb 20 2021, 12:14 AM.

Details

Reviewers

imp
allanjude
nwhitehorn
rgrimes

Summary

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 https://wiki.archlinux.org/index.php/EFI_system_partition
systemd https://github.com/systemd/systemd/pull/3757#issuecomment-234290236

Diff Detail

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

Update the other locations

Herald added a subscriber: bdrewery. · View Herald TranscriptFeb 20 2021, 12:14 AM

Remove old /boot/efi too

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.

nwhitehorn mentioned this in D28897: Mount ESP on newly-installed systems.Feb 23 2021, 3:09 PM

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

Update after 0b7472b3d8d2f1e90fade5236b44fd98d8e396c2

This revision now requires review to proceed.Mar 3 2021, 2:17 PM

Herald added a subscriber: andrew. · View Herald TranscriptMar 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.

ObsoleteFiles.inc
40	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.
release/tools/vmimage.subr
238	Since we are touching this line I would really like to see mkdir -> install -d with full explicity owner/group/modes here.
share/mk/bsd.own.mk
183	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.
usr.sbin/bsdinstall/partedit/partedit_efi.c
88	Anyway for this to reach into the make variables?
usr.sbin/bsdinstall/partedit/partedit_x86.c
117	Same here, can we use ${EFIDIR} some how?