Re: Quieter startup + working experience by overriding VT_CONSWINDOW (and consequences)

> On 18. Feb 2025, at 13:31, Steven Harms (High-Security Mail) <sgharms@stevengharms.com> wrote:
> 
> Greetings,
> 
> As per previous thread, I am still interested in a quieter fbsd experience: ideally no kernel / rc output on startup and no console messages on default TTY after login. 
> 
> As I was trying to see if I could extend boot_mute, I came across another approach:
> 
> set the default console to not-zero (e.g. 4)
> But then the default login prompt was also ttyv4. So I....
> Added a kernel option whereby to specify which VT the starting one (instead of following to e.g. 4).
> (supporting code to make all that work)
> Pair with the status quo boot_mute, you get a remarkably quiet boot up. Logo, black screen (as your getty session waits), prompt.
> 
> Mea Culpa: I'm waaaaayyy out of my depth on the kernel hacking piece (just enough C to be dangerous). Consider these sketches. https://github.com/freebsd/freebsd-src/pull/1600
> 
> The suggestion separates "Which VT gets the console" and "Which VT is the starting VT." These two roles are conflated and my sketch unwinds that. Hereby one gets:
> 
> a nice quiet boot up
> a default login screen whose vi session isn't interrupted (by default) with noise from your wificard (if you're on laptop fbsd) -- frightening/annoying to some
> a dedicated live sink for console messages (versus a log file or versus your vi session) closer to a real serial console or OSX's console.app
> 
> Is this a better approach vs extending boot_mute's run? Or if this is wrong-headed I'll go back to previous paths of inquiry.
> 
> Steven

I personally like the approach to enable console log with boot -v, otherwise use your syslog kern.* once userland is there and internal message buffer for  startup time before userland appears. This makes it possible to have quick check (-v) and for normal startup, we still have the information or in case of crash, we can check the message buffer… 

rgds,
toomas