05.04.2025 13:37, Mark Kettenis пишет:
>> Date: Sat, 5 Apr 2025 11:42:44 +0200
>> From: Peter Hessler <[email protected]>
>>
>> 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 <[email protected]>
>> :> 
>> :> 29.03.2025 18:51, Mark Kettenis пишет:
>> :> >> From: "Theo de Raadt" <[email protected]>
>> :> >> Date: Sat, 29 Mar 2025 09:35:34 -0600
>> :> >>
>> :> >> Stuart Henderson <[email protected]> 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.

MODE is "install" or "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.

Agreed, plus installboot(8) alread does the MD dance for us.

>
>> 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

Usual style is to omit curly braces for variables, stick to [[ which is
fine without quotes and have an empty line after locals declaration
inside functions.

On BIOS/MBR -c is a NOOP, but for clarify I'd do that only under MDEFI.

>>              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.
>>

Reply via email to