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

[emaste]

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

[emaste]

Update the other locations

[emaste]

Remove old /boot/efi too

[imp]

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.

[nwhitehorn]

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]

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.

[emaste]

Update after 0b7472b3d8d2f1e90fade5236b44fd98d8e396c2

[nwhitehorn]

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.

[rgrimes]

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?