On Fri, Mar 21, 2025 at 4:13 PM Steven Harms (High-Security Mail) < sgha...@stevengharms.com> wrote:
> Folks, > > I am attempting to figure out what boot_mute wants me to do. > It turns off output to the console. You probably don't want this option. Or at least, in the past this option was for something else. > I'm trying to make a "laptop guide" and I'm confused. I'm not a C > programmer at this scale of sophistication so there's a decent chance I'm > foolishly making an error, but current is not doing what I expect. > > > 1. boot_mute doesn't appear in [loader.conf(8)][1] > > We should add it to the man page. Especially since its meaning has changed through time from a niche option that we specifically didn't document to one that's in use. Originally, it was designed for router companies and similar that have lots of output on boot that what to have a console in case of panics. But it was repurposed when in 2013 vt was merged and it wasn't noticed due to the size of the code coming in. Originally, it was done by Whistle in 1993 for muting the console on their WhistleJet internet systems since it printed things Whistle generally didn't want disclosed. So this was intentional, but lead to a bad outcome since the vt(4) authors weren't aware of this when vt was merged, and none of the reviewer caught it. > > 1. In the defaults/loader.conf file it [appears][2] and says: that it > exists to mute the console. I daresay that it's doing more than that, > because activating it puts a logo + beastie orb on the screen. Question: > Should the comment be updated? > > Not quite. The logo + beastie orb is the preferred way for graphics consoles to have graphics all the way from the boot loader until X11 starts. > > 1. The only other mention of boot_mute is on the line that specifies > that the overlay image can be controlled through configuration of the > [splash] value implying that instead of using the encoded array of > unsigned char in the kernel at > > https://github.com/freebsd/freebsd-src/blob/main/sys/dev/vt/logo/logo_beastie.c. > Whoa! > A nice configurable option? Nice. Looking at the git history on that file > it appears to be part of splash(4). And /that/ document says ..."work with > syscons(4) > only". OK so maybe that comment in defaults also needs updating? Because... > > I'm surprised by this, actually. We pass the splash screen into the kernel from the boot loader. splash(4) is a different thing than this, however, and does only work with syscons which is actively being removed from the kernel. Prior to vt(4) coming into the system, you wouldn't set boot_mute, but one of the splash variables and it would just stay in place from the boot loader all the way through. Finding this in vt/logo surprises me. It looks like this has changed, which is unfortunate. boot_mute originally meant something else. Since this was botched in 2013 with the vt merge, though, I don't see how we put it back to its original meaning. Though, honestly, having a kenv to control this would be better and we could phase out the boot_mute entanglement. It is documented, kinda, in splash(4), as two lines at the end of a huge amount of text that's not relevant anymore unless you use syscons. So it's there, but buried. The man page needs to be completely revamped. The other caveat: if you booted in 'text' mode (which you are unlikely to do on a laptop, but would if you enable a dual console with serial you are), then we don't load it. > > 1. My impression is that vt(4) is the way forward at present which > means that I was following a bad path and we're /back/ to using the > [in-kernel defined image][3] for the splash screen that's triggered by > boot_mute? I really don't understand the image packing as chars well enough > to reverse how to create a BMP from an array of hex values, but, eh...is > this the one that's being shown? Seems like it. There's also quite a > bit of logic inside of sys/dev/vt/vt_cpulogos.c[3] that suggests that it's > trying to use arrays of chars as overlay. > > Yea, compiling into the kernel is discouraged. It was originally a niche thing and now that the boot loader can handle it, that's best ignored. > OK, so AFAICT, there are two terminal rendering systems, > under-/mis-documented loader.conf flags, and two places where images are > defined: in the vt device directory and the images/ directory. Question: > Can anyone confirm / deny my assessment? > It's a mess. There's how it kinda works, and then how it should work and the dearth of documentation exacerbates this (but when boot mute came in and then later when vt bogusly(IMHO) repurposed this). > After all that I'm still a bit confused as to what the expected/desired > behavior is. Can anyone help me figure out what the desired behavior is > (and maybe I can update the comments)? My current plan is to turn the array > into 0x00 and see what happens, but I'd like to know how I can turn the > results of that experiment into a patch. > Short term, your best bet is to use boot_mute=YES and change splash in loader.conf to get the image you want. Longer term we need to fix this to decouple the two, though we likely need to have a release or two where they both do things (and possibly fix bugs in vt(4) when a splash screen is present that lead it to outputting text). But that's a bigger discussion in the community and it's possible others don't share my vision for a path forward. Warner > Best, > > Steven > > [1]: > https://github.com/freebsd/freebsd-src/blob/main/stand/defaults/loader.conf.5 > [2]: > https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867e4084bafe368c47f6c038/stand/defaults/loader.conf#L134 > [splash]: > https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867e4084bafe368c47f6c038/stand/defaults/loader.conf#L30 > [3]: > https://github.com/freebsd/freebsd-src/blob/main/sys/dev/vt/vt_cpulogos.c#L79-L91 > --- > > Public Key: 22BE39E2FA68D8BA8DC4B43A55A16D8CE2B036DE > > Messages from this account are considered the best-secured and most > reliable. Send information regarding health, wealth, or requiring higher > standards of security to this address. > > Sent with Proton Mail <https://proton.me/mail/home> secure email. >
