Re: [PATCH] BIOS boot vs EFI system partition mountpoint
Taylor R Campbell <[email protected]> Sat, 20 Aug 2022 21:08:36 +0000
| Newsgroups | gmane.os.netbsd.ports.x86-64,gmane.os.netbsd.ports.i386 |
|---|---|
| Message-ID | <[email protected]> |
> Date: Sat, 20 Aug 2022 12:28:31 -0700 > From: Brian Buhrow <[email protected]> > > hello. I fully agree with Robert, and for the same reason. > Updating boot blocks unnecessarily is always a dicey > proposition,especially when updating machines that are far away from > knowledgable hands. Can you please quote the part of my proposal or patch that involves updating existing boot blocks? The point is to allow _new_ images and installations to support BIOS and EFI boot at the same time and have a standard mount point for the EFI system partition. Even if you go out of your way to use installboot(8) on your system to install a new primary bootloader with my patch, and even if you don't mv /boot /biosboot, the new primary bootloader will continue to find the old secondary bootloader at /boot. > To that end, I suggest /efiboot as a mount point. It tells what it > is, and if another booting technology comes along, it won't conflict > with that. Do you propose that it be different from what other platforms use, so we don't end up with a standard mount point for the EFI system partition? Or do you propose to change other modern platforms to use /efiboot instead of /boot as they currently do? Will you volunteer to implement the changes for your alternative proposal? Note that on evbarm (and likely riscv), where /boot is a mount point for the EFI partition on EFI systems, it is shared as a mount point for device tree blobs on non-EFI systems and for other data such as boot.cfg and cred_msdos(8). The same mount point is also used by evbmips for device tree blobs and other data, but evbmips doesn't do EFI boot at all as far as I know.