You could test directly EFI/FreeBSD and mkdir -p

This will break system that don't have persistant variable, for those we need to use EFI/BOOT/boot${arch}.efi

On some system you will not have efirt for variable, can efibootmgr test this ?

It might be nice to also accept an ESP directly to install it into, as well as auto detect.
As well as having the full unix path for ESPs that are already mounted.

You need markup on loader.efi

You need markup on these file names.

I'd be tempted to line the echos up with the echo below.

Does this cope with boot1.ef?

You can return 0 here.

and return 1 here.

If you make the changes I suggested, this can turn into a simple

if bootefi_is_freebsd; then

which seems less convoluted to me.

It doesn't today, but we can do the right thing with efivar if uboot's EFI rejects permanent changes to variables.

I think we also need to test this with bhyve+UEFI, but I suspect (IIRC) both implementations accept the UEFI vars and they just don't persist.

So in that case we definitely do _not_ want to remove the EFI/BOOT/BOOT{$arch}.efi file.
And for new installs, I also need to check the changes I committed a few weeks ago to install /EFI/FreeBSD/loader.efi only. I seem to recall @imp was against having the BOOT${arch}.efi file since it's supposedly only for removable media, but there are obviously several situations where it's needed for booting from fixed media too.

[ -n ${verbose} ] && echo $*

should suffice. You don't need the extra stuff $@ does, nor the extra quotes, nor even the if.

Was "boot1.ef" a typo? It copes with boot1.efi, but not currently loader.efi. Since we'll want to keep this file, I'll update it to check for strings that are in loader.efi too.

Except since the script is set -e, that then needs a || true to avoid the statement causing an error.

In the latest revision of the script I've changed it so that if /EFI/BOOT/BOOT${arch}.efi exists, it will copy loader.efi to that file.
In addition, if EFI/FreeBSD/loader.efi exists, it will also copy loader.efi to that file. I think that should work to retain any boot functionality.

The script already does accept an ESP directly to install into - via the -d option.
I agree having an option to specify a unix path for an already mounted ESP would be nice to have too.

In the latest revision they look lined up in QtCreator, but for some reason they're wrong here - I'm using tabs, not spaces.

This should take into an account an ESP we're copying to already having been mounted. For some images, it'll be premounted at /boot/msdos (or something relevant, like /boot/efi or /efi) and we probably should just use that mountpoint rather than mounting/unmounting it. We'll need to be careful about not unmounting it in cleanup, too, if that's the case.

This block should be redundant now; we've guaranteed just above that we either have non-zero user supplied ${esps} or we failed to autodetect ESP and bailed out with the "Error: could not detect ESP containing FreeBSD loader to update"

Good point. I've fixed this in the latest revision and tested on a Beaglebone Black where the ESP is mounted on /boot/msdos.

Thanks, I've fixed it in the latest diff.

I've added a -p path option to the latest revision of the script and man page.

I think with this approach, you'll need to also set some local indicator that esppath should be cleared out just after you don't unmount/rmdir the mntpt. Otherwise, subsequent copyloader will suddenly fail as we can't clobber the already-mounted ESP that we don't want to touch.

This is likely really really edge-casey, though...

what if it was mounted RO?

I guess we should keep track of auto-detected ESP vs. user-specified ESP. If user-specified it, we should probably re-mount it R/W and then return it to R/O when we're done, no?

Good point.

Yeah, we probably should do that, instead of erroring out if it's mounted RO.