NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/56862: boot.cfg bug with userconf
The following reply was made to PR bin/56862; it has been noted by GNATS.
From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: Valery Ushakov <uwe%stderr.spb.ru@localhost>, Thomas Klausner <wiz%NetBSD.org@localhost>
Subject: Re: bin/56862: boot.cfg bug with userconf
Date: Wed, 8 Jun 2022 21:59:01 +0000 (UTC)
On Sun, 5 Jun 2022, Valery Ushakov wrote:
> Also, #ifndef SMALL around that original hunk was ... not thought
> through, as it doesn't just compile out some functionality, but
> changes the semantic of the command based on which boot block you use.
>
> So I think your original patch to to drop that hunk is the right
> course of action, but we need to find all the places - your patch
> changes sys/arch/i386/stand/efiboot/boot.c but the other PR is about
> the original change in stand/boot that was later cloned to efiboot it
> seems.
>
There is another problem here: if we have a boot.cfg like
this:
```
menu=Boot normally:gop 0;rndseed /var/db/entropy-file; userconf disable alc*;boot
menu=Boot single user:rndseed /var/db/entropy-file;boot -s
menu=Boot TEST:gop 0;rndseed /var/db/entropy-file;boot NAME=NetBSD_test:
menu=Boot TEST single user:rndseed /var/db/entropy-file;boot NAME=NetBSD_test: -s
menu=Drop to boot prompt:prompt
default=1
timeout=10
clear=1
userconf=disable i915drmkms*
```
then if item 1 is selected, 2 devices (i915drmkms* & alc*) are
disabled. Fine so far. But, if item 1 fails for some reason, and
user selects item 3, then this too boots with alc* disabled, which
is not intuitive.
It should be pretty easy to "roll-back" to the global strings each
time a menu item is re-entered, either by keeping separate global
and per-menu linked lists or by adding a "marker" to denote the end
of the global strings in the current single list. Can't test this
until the weekend, though...
On Mon, 6 Jun 2022, Thomas Klausner wrote:
> I found two places that call bootdefault():
>
> sys/arch/i386/stand/boot/boot2.c
> 493: bootdefault();
>
> sys/arch/i386/stand/efiboot/boot.c
> 457: bootdefault();
>
> and two implementations:
>
> sys/stand/efiboot/bootmenu.c
> 137:bootdefault(void)
>
> sys/arch/i386/stand/lib/bootmenu.c
> 132:bootdefault(void)
>
Yep. That looks like what I got.
-RVP
Home |
Main Index |
Thread Index |
Old Index