> 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.
Index: usr.sbin/installboot/efi_bootmgr.c
===================================================================
RCS file: /cvs/src/usr.sbin/installboot/efi_bootmgr.c,v
diff -u -p -r1.4 efi_bootmgr.c
--- usr.sbin/installboot/efi_bootmgr.c 4 Mar 2025 20:40:48 -0000 1.4
+++ usr.sbin/installboot/efi_bootmgr.c 30 Mar 2025 15:28:46 -0000
@@ -297,10 +297,7 @@ write_efi_load_option(EFI_LOAD_OPTION *o
break;
}
}
- if (found) {
- memmove(&data[2], &data[0], i);
- *(uint16_t *)&data[0] = idx;
- } else {
+ if (!found) {
/*
* If there are more than 256 load options, simply
* give up.
