Port-amd64 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] BIOS boot vs EFI system partition mountpoint
> Date: Sun, 21 Aug 2022 01:11:39 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
>
> 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.
Home |
Main Index |
Thread Index |
Old Index