Re: [PATCH] BIOS boot vs EFI system partition mountpoint
Taylor R Campbell <[email protected]> Sat, 20 Aug 2022 22:07:08 +0000
| Newsgroups | gmane.os.netbsd.ports.x86-64,gmane.os.netbsd.ports.i386 |
|---|---|
| Message-ID | <[email protected]> |
> Date: Sun, 21 Aug 2022 01:11:39 +0700 > From: Robert Elz <[email protected]> > > 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? Supopose you used sysinst to install NetBSD on ~any x86 machine of the last decade, but you it did with sysinst prior to EFI support, from NetBSD<9. You have an installation that can be booted with BIOS but not with EFI. What happens on update? => If you update sets on this installation to NetBSD 9, it will still boot with BIOS and not EFI. If you run postinstall, etcupdate, &c., it will still boot with BIOS and not with EFI -- none of this will touch the bootloader. => But if you use sysinst to install a fresh NetBSD 9 on the same machine, you'll have an installation that can be booted with EFI but not with BIOS. Is this a problem? On the one hand, it would be nice to have an update procedure that gives exactly the same result as a fresh install. On the other hand, that would necessarily require updating the bootloader, which as you noted is risky (or it would require ditching support for EFI in sysinst, which is a nonstarter). The change I'm proposing is much less risky than that: it just gives us the latitude to make _new_ installations use /boot as a mount point, just like evbarm and evbmips (and riscv) do. Which requires adding a line to fstab -- again, something that a new sysinst might do for new installs, but something that extracting sets, running postinstall, &c., won't do for existing ones. Existing installations are unaffected by this change.