Page MenuHomeFreeBSD

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

Authored by emaste on Feb 20 2021, 12:14 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 21 2024, 3:26 PM
Unknown Object (File)
Jan 31 2024, 7:30 AM
Unknown Object (File)
Jan 14 2024, 10:43 PM
Unknown Object (File)
Jan 10 2024, 8:11 AM
Unknown Object (File)
Dec 23 2023, 1:31 AM
Unknown Object (File)
Dec 13 2023, 3:52 PM
Unknown Object (File)
Dec 11 2023, 1:19 AM
Unknown Object (File)
Nov 10 2023, 2:23 AM

Details

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

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.

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 ↗(On Diff #85050)

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 ↗(On Diff #85050)

Anyway for this to reach into the make variables?

usr.sbin/bsdinstall/partedit/partedit_x86.c
117 ↗(On Diff #85050)

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