[PATCH] BIOS boot vs EFI system partition mountpoint

[Greg Troxel]

My quick reaction is that the use of /boot for the 2nd-stage bootloader
is really longstanding, and that mounting some boot partition (EFI or
not) on /boot is much more recent.

I have a boot partition mounted on /grub, on a xen domU that uses pvgrub
(because that's how the dom0 is). I wouldn't mind renaming that to
align if there were a convention. That machine has a /boot which isn't
used, but is the standard image.

That leads me to want to have a new name for the boot partition, and
leave /boot alone. And, mounting the EFI partition is not critical;
it's great to have it in a standard place because upgrade tools have to
mess with it, etc., but I think the system will boot just fine even if
it isn't mounted.

I think the hard part is coming up with a sane name for where to mount
this. After a few minutes, my suggestion is /bootfs which conveys that
not only is this for booting, but that it's a mount point for a
filesystem, not a boot program. I see that as causing less total
torquing around over all users.

[Manuel Bouyer]

Date: Sat, 20 Aug 2022 12:00:31 +0000
| I'd like to have a standard mount point for the EFI system partition
| on platforms with EFI boot.
I use /efi ... just seemed like the obvious thing to do to me.
| I propose to change NetBSD/x86 BIOS boot so it looks for the secondary
| bootloader at /biosboot instead of /boot, but falls back to /boot.
I think that's a very poor idea, sorry. Not what that paragraph implies,
but ...
| and we can have /boot as the standard mount point for ESP on
| platforms with EFI boot.
this which it enables, as x86 platforms are one of the systems which
use EFI boot, and while when using EFI to boot, /boot is irrelevant,
not all x86 systems use it. If we start making distributions where
/boot is a directory, then lots of those systems are going to fail.
Of course they wouldn't if they have installed the new version of the PBR
boot blocks, but I know of lots of people who essentially never do that.
They have happily done NetBSD upgrades (major version upgrades) without
touching anything outside the NetBSD filesystems. At least since we
stopped encoding the /boot block numbers in the PBR boot code. The boot
blocks work, updating them to something which should work, but who knows
since this is all BIOS using code, and no-one can test against every
ancient BOIS that ever existed, is dangerous.
I am using EFI booting now, so this isn't immediately relevant directly,
but I an assure you that I was one of the people who did what I just
described, I'd never upgrade working boot blocks if there was any
alternative.
Please leave /boot as it is (on x86 and arm and anything else that uses
something of that name) and make a new standard place for mounting the ESP.
That can be /efi (which I am currently using) or anywhere else that seems
reasonable (I can easily update my fstab), just not /boot (not on arm
systems either, unless there is some very good reason that it has to be
that way, which I very much doubt - the ESP should contain nothing that
is needed while the system is running, except when there is a need to
update it - my /efi is "noauto" in fstab, and I almost never mount it).

seconded.

[Manuel Bouyer]

Date: Sat, 20 Aug 2022 20:45:29 +0700
Of course they wouldn't if they have installed the new version of the PBR
boot blocks, but I know of lots of people who essentially never do that.
They have happily done NetBSD upgrades (major version upgrades) without
touching anything outside the NetBSD filesystems. At least since we
stopped encoding the /boot block numbers in the PBR boot code. The boot
blocks work, updating them to something which should work, but who knows
since this is all BIOS using code, and no-one can test against every
ancient BOIS that ever existed, is dangerous.

(a) leave the bootloader as is, and it will continue to work with no
change, or
(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).
Nothing in this change will automatically move /boot to /biosboot. 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).
What is the specific problem you foresee?

/boot can either be a directory or a file and upgrade tools will have to
deal with that (with the risk of ending up with an unbootable system if
things go wrong)

Please leave /boot as it is (on x86 and arm and anything else that uses
something of that name) and make a new standard place for mounting the ESP.
That can be /efi (which I am currently using) or anywhere else that seems
reasonable (I can easily update my fstab), just not /boot (not on arm
systems either, unless there is some very good reason that it has to be
that way, which I very much doubt - the ESP should contain nothing that
is needed while the system is running, except when there is a need to
update it - my /efi is "noauto" in fstab, and I almost never mount it).

The EFI system partition is already mounted by default at /boot on
evbarm and riscv. That mount point serves a dual purpose both for efi
boot and for fdt boot, and for related things like creds_msdos(8), so
that, e.g., you can update device tree data by extracting a newer
dtb.tgz. The evbmips generic and octeon images also use /boot for dtb
(not sure any of them boot with EFI). x86 is the odd one out here.

To me it looks like easier and less error-prone to rename /boot to /efi
on these systems than change the purpose of exising /boot on x86.

[Martin Husemann]

(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).

Minor nit: GPT is unrelated here, but the disk needs to have space
for a new EFI System Partition (or already have one). You can UEFI-boot
MBR partitioned disks just fine.

I guess the main point of confusion is that you can't add /boot as a directory
to the mtree specials file or similar (or find/add some mtree notation that
allows it to be a file instead), and that you are not going to create
a directory /boot on updates (but would do so on new installs, via
sysinst at runtime, and not include the dir in any sets).

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Please leave /boot as it is (on x86 and arm and anything else that uses
something of that name) and make a new standard place for mounting the ESP.
That can be /efi (which I am currently using) or anywhere else that seems

On ARM, /boot *is* the ESP. (It’s also whee the DTB files live, and U-Boot loads them from there but then invokes our EFI boot loader to load the kernel).

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de