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