> Date: Sat, 5 Apr 2025 11:42:44 +0200
> From: Peter Hessler <phess...@theapt.org>
>
> On 2025 Mar 30 (Sun) at 17:47:16 +0200 (+0200), Mark Kettenis wrote:
> :> Date: Sat, 29 Mar 2025 16:26:16 +0000
> :> From: Klemens Nanni <k...@openbsd.org>
> :>
> :> 29.03.2025 18:51, Mark Kettenis пишет:
> :> >> From: "Theo de Raadt" <dera...@openbsd.org>
> :> >> Date: Sat, 29 Mar 2025 09:35:34 -0600
> :> >>
> :> >> Stuart Henderson <s...@spacehopper.org> wrote:
> :> >>
> :> >>> On 2025/03/29 14:30, Klemens Nanni wrote:
> :> >>>> 23.03.2025 19:30, Sven Wolf пишет:
> :> >>>>> since some weeks, after I run 'sysupgrade -n -s -k' and installed
> the current snapshot, the boot order in UEFI gets changed.
> :> >>>>
> :> >>>> This is intended, OpenBSD attempts to ensure that it is booted by
> default.
> :> >>>>
> :> >>>>> I there a way to disable this behavior?
> :> >>>>
> :> >>>> No.
> :> >>>
> :> >>> Probably makes sense for install but this seems a pretty bad idea
> after an
> :> >>> update.
> :> >>
> :> >> Yeah, that's possibly the right conclusion. A conditional in the
> :> >> script might be required.
> :> >
> :> > The solution I had in mind was to do the following:
> :> >
> :> > * If the OpenBSD Boot#### boot option doesn't exist, create it and
> :> > prepend it to the BootOrder list.
> :> >
> :> > * If the OpenBSD Boot#### boot option exists, do nothing (and leave
> :> > BootOrder alone).
> :>
> :> That would default to OpenBSD once and then leave it alone for users
> :> to reorder, which seems like a better approach for both sides.
> :
> :Diff below implements that approach.
> :
> :> > If we do this, we may want to set the BootNext variable such that a
> :> > reboot boots OpenBSD and finishes the install.
> :>
> :> On install OpenBSD's Boot#### is not expected to be there, but if it is,
> this
> :> would ensure we follow through without messing with existing order.
> :
> :Right. So if you end up uninstalling OpenBSD and reinstall it later,
> :it might not boot into OpenBSD by default.
> :
> :> Upgrades should do this either way... any reason not to always set
> BootNext?
> :
> :Not sure what you're trying to say here. The only reason I see for
> :not setting BootNext is when someone runs installboot -c manually and
> :doesn't immediately reboot. Then booting into OpenBSD might come as a
> :surprise when the system gets rebooted eventually. I don't think this
> :would be a huge issue.
> :
>
> Here is an alternative approach, only set those variables during an
> install, not an upgrade. IMHO this matches what people would expect,
> that during install we take over the system and during upgrade we leave
> external things alone.
>
> Since we don't have a dedicated Install or Upgrade variable, pick basd on
> DISKS_DONE which is only set in Install, and not during Upgrade.
>
> Untested, and needs the same change on other EFI-compatibe arches.
The downside of this approach is that it means that people upgrading
from previous releases will not get the EFI boot entries.
And of course, instead of removing lines, you're adding lines.
> Index: distrib/amd64/common/install.md
> ===================================================================
> RCS file: /cvs/openbsd/src/distrib/amd64/common/install.md,v
> diff -u -p -u -p -r1.66 install.md
> --- distrib/amd64/common/install.md 29 Mar 2025 14:26:41 -0000 1.66
> +++ distrib/amd64/common/install.md 5 Apr 2025 09:36:31 -0000
> @@ -41,7 +41,11 @@ grep -q -e '^efifb0 at mainbus0' -e '^ac
> $DMESGBOOT && MDEFI=y
>
> md_installboot() {
> - if ! installboot -cr /mnt ${1}; then
> + local _flags='-r'
> + # If we are installing, set EFI flags
> + [ -n "$DISKS_DONE" ] && _flags='-cr'
> +
> + if ! installboot $_flags /mnt ${1}; then
> echo "\nFailed to install bootblocks."
> echo "You will not be able to boot OpenBSD from ${1}."
> exit
>
>
>
>
> --
> Committees have become so important nowadays that subcommittees have to
> be appointed to do the work.
>
