Re: [PATCH] BIOS boot vs EFI system partition mountpoint

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 20 Aug 2022 16:14:46 +0000
    From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
    Message-ID:  <20220820161441.BDEFD609EB%jupiter.mumble.net@localhost>

  | Users who update these systems can either:
  |
  | (a) leave the bootloader as is, and it will continue to work with no
  | change, or

You're presuming a lot about the update method.

  | (b) update the primary bootloader with installboot and move /boot to
  | /biosboot if they want to turn the existing image into a hybrid image
  | that can also be booted with EFI (assuming it's already on a GPT).

You mean manually?   Really?

  | Nothing in this change will automatically move /boot to /biosboot.

When one builds a system (if that change gets included) what
gets complied and installed in ${RELEASEDIR}/ and then in the
base.tgz set?   /boot or /biosboot?   What do the sets lists
expect to exist?   Does the mtree file contain /boot as a directory
that needs to be created, or not?

  | It will just cause new installations to use /biosboot instead of /boot
  | (but still support /boot if you, e.g., untar an old file system's
  | contents into a new file system).

I am not sure I like the idea of an upgraded system being different
(local config excepted of course) from a newly installed version
of the same system.  Would that mean that after -10 is released
people would need to identify whether their -10 is a new -10 or
an upgraded one when submitting PRs or asking about problems?

[I was interrupted at this point about 85 mins ago ... I see that
there have been several more replies, I have read them all, or at
least all that were avaikable before I resumed here.]

  | What is the specific problem you foresee?

See above, other replies, and just general confusion.

This all looks similar to me to the c/d raw partition variation.
That has a bigger impact on average users than this yet has never
been fixed - and for good reason.

  | The EFI system partition is already mounted by default at /boot on
  | evbarm and riscv.

OK, then leave it like that on those ports that have it that way.

  | Part of the purpose is to make a standard mount point so that
  | automatic upgrade tools can work more reliably.

More reliably deal with /boot remaining a (bios) executable
in some setups?   Really?

  | Obviously if /boot is
  | not a directory then such tools would have to fall back to manual
  | intervention for legacy systems.

Nonsense.

	if [ -d /boot ]
	then
		ESP=/boot
	elif [ -d /efi ]  # or whatever is chosen
	then
		ESP=/efi # ...
	else
		abort 'No existing ESP'
		# Alternately, just make one, depending on
		# what this tool is, and the architecture default
	fi
	cd "${ESP}" || abort HELP
	...

and the equivalent C code, which could be embedded in a libutil
library function, to avoid duplication (and errors).  Such a function
would take a bool 'create' param to deal with the 'Alternately...'.

Almost anything is better than risking breaking booting, for anyone.

kre