> On 18. Feb 2025, at 13:31, Steven Harms (High-Security Mail) > <sgha...@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
