Re: Adjustments to userland for a quieter startup (RC system)
if i read what hellosystem did to whole init, i can't see how it could be implemented easily, nevermind it being default. they also disabled ttys and everything unsure what the solution would be here there are number of custom fbsd inits, even i have it, with defaults unlikely to be suitable for anyone except me. i have plans to take some of that and add as features to see if they would have use elsewhere i never looked, can you disable kernel output too? someone suggested redirecting output to serial where it disappears or using splashes. that, of course hides everything. can't even debug errors. it's like windows system, if you ask someone to help you, they might ask what's on the screen, then you say nothing, it just sits the with empty screen. then helper would be like oh bummer too. it's all nice quiet and dumb maybe there could be midpoint here. maybe some key or something. unsure how it would work tho. as it goes from loader to kernel to init/multiuser i get the issue, just can't think of easy solution here that wouldn't piss off others. by watching init, it's easy to spot setup errors. yeah, granted, if you even know what it all means i'm thinking of what linux distros do. they are more common on laptops. i haven't heard them hiding all and nor do i hear massive complaints about "machine scribberish"? who knows what the real solution is. patch init to hell and back, to include all that. make special desktop overlay, so the granny won't ask son, what's the wlan0? remember, init still needs to be fast and usable after all this work and maybe it can't be default. nevermind that current install is inherently unfriendly and doesn't really allow one to boot into open firefox home page easily. and who can make it happen, are unlikely to be bothered with messages i get the problem tho also, when people, maybe not on fbsd but else where, complained that it boots over a minute, how can it be. who even boots machines that much. that was for servers. maybe laptops get booted nore often, esp. how the suspend doesn't often work and nevermind to disk, that's not even implemented. so people boot. also, is this recent or what. systems have booted for some time since forever. ok this is about time, not messages. maybe times indeed need blank screens with nice images i'm like, when i reboot android phone, i often wonder why does it shutdown or init that long. i wish i could see, if i want, what it does. i bet here it's similar, how to, like, get messages if needed, all, of one wants, and definitely any irrecoverable errors, eg failed storage or so maybe i have use for it on my own even if somebody comes out with all around good solution
Re: Adjustments to userland for a quieter startup (RC system)
On Sunday, February 2nd, 2025 at 2:38 PM, Tomek CEDRO wrote: > One "black box" scenario that came to my mind we did not mention is > some embedded system that we really do not want to show anything OS > related just the final login prompt.. or was that the initial idea? That wasn't one of my main drivers, but once you settle that position at one extreme (silence) versus say a class on learning kernel design (maximal verbosity using FreeBSD as platform), it suggests that an RC mechanism that supports the full range of verbosity is useful. > Log levels is just an idea for generic commonly practiced solution > that may be applied to rc/init, you replace echo / printf with > log(lvl, fmsg, ..), but its quite a big task and not sure if really > critical right now / worth the time..? Is it critical? Probably not. Supporting more video hardware and wifi cards is critical. But is it more than just mere chrome polishing? I think so. It's the first chance to show the market what the FreeBSD way looks like; it's a chance to show that it's not _entirely_ spartan. There's some consideration to taste and design. While Apple represents an extreme case, how the box feels when it's opened is a legitimate concern. How the laptop looks at boot, I think, is a similar concern. > > Sadly boot_mute="YES" was insufficient as well. It only seems to mute > > /kernel/-level diagnostics. Afterward, my screen was still full of > > RC-originating content. And yes, suppose we /could/ do an overlay until the > > login prompt -- I think that should be supported. It's what I expected > > boot_mute=YES to do by default, frankly. > > > Looks like the boot logo screen component needs an update, so it > covers the rc scripts too, and maybe show some animated spinner > indicating working stuff in the background, and this should fix the > problem right? Most systems work that way already, and pressing Tab or > Esc jumps to the log messages easily when necessary / possible / > allowed. I support this implementation. boot_mute=YES hides all diagnostic data up to the prompt being ready (surely one could hook getty's code for an ioctl?). I also think that ESC as a means for getting to the full diagnostics as in status quo is a great place to debug uh-oh moments. It's beyond my capability to size this story, *but* I can't imagine it being a weeks-long effort. Steven
Re: Adjustments to userland for a quieter startup (RC system)
On Sun, Feb 2, 2025 at 11:19 AM Steven Harms (High-Security Mail) wrote: > > Okay, I am sorry, I mixed the general idea with detailed PR that aims > > just updating routing and devmatch parts with user selectable option > > not changing a defaults, thus my previous remarks are invalid and > > updated, I apologize! :-) > > A goal of this PR was to flush out dialogue around whether there was a > universal noise level-adjusting knob in the RC system. [jlduran]'s more > ambitious PR, my PR, and the discussion to this post suggest "no." I think > it's probably right to generalize the discussion! > > I also realize that this is a probably a controversial perspective. My > motivation here is ultimately service to the FreeBSD Laptop project. Windows > and OSX have conditioned many in the population of the FreeBSD-curious to > expect a lot less text on startup if things are going well. Thank you Steven, and my apologies once again to mix things up badly, I feel ashamed, I need to sleep more as my 8-bit Neural Network CPU does not seem to cope with this surrounding world "innovation" and multitasking :-P Yes that would be a controversial decision to change defaults to mute and get rid of boot/rc messages, thus my inital allergic reaction, sorry :D But its always good to talk things over maybe a new solution can show up that way and will not flip everything upside down over and over again :-) One "black box" scenario that came to my mind we did not mention is some embedded system that we really do not want to show anything OS related just the final login prompt.. or was that the initial idea? > To those who say "Yes, seeing the diagnostic data is why FreeBSD is so > great," I say: In a server/device context, I'd not change anything (something > my PR may have flubbed in its implementation). ***But***, I contend that for > FreeBSD to thrive on a wider population of laptops and access a wider > population of users, some options (including such a noise knob for the RC > system) ought be available. The extent that [helloSystem] went to hide > messages suggests an unmet need. > > [helloSystem]: > https://hellosystem.github.io/docs/developer/boot.html#boot-mute > [jlduran]: https://github.com/jlduran/freebsd-src/pull/90/files > (..) > > * I guess the idea is to silence the terminal? How many flags need to > > be put to silent instead just one? Why not just put a boot logo image > > if you really do not want to see the boot messages? It may provide > > expected user experience and will not impact diagnostic information > > that are usually useful :-) > > Sadly boot_mute="YES" was insufficient as well. It only seems to mute > /kernel/-level diagnostics. Afterward, my screen was still full of > RC-originating content. And yes, suppose we /could/ do an overlay until the > login prompt -- I think that should be supported. It's what I _expected_ > boot_mute=YES to do by default, frankly. Looks like the boot logo screen component needs an update, so it covers the rc scripts too, and maybe show some animated spinner indicating working stuff in the background, and this should fix the problem right? Most systems work that way already, and pressing Tab or Esc jumps to the log messages easily when necessary / possible / allowed. Log levels is just an idea for generic commonly practiced solution that may be applied to rc/init, you replace echo / printf with log(lvl, fmsg, ..), but its quite a big task and not sure if really critical right now / worth the time..? Thank you :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Adjustments to userland for a quieter startup (RC system)
I'm just going to throw this idea out here: Various non-UNIX operating systems dedicate a small piece of raw disk to logging purposes, and stick everything on there, instead of blasting it at users, who seldom care and cannot read that fast anyway. The big advantage is that the log is incredibly robust, as long as the disk works, it gets recorded. But the log is also easy to get to, both from a running system and from a disk which is beyond repair. Admittedly, most of the systems I have seen this on, had simple disk-controller interfaces, whereas we have who knows how many different kinds of devices and interfaces which masqurade as "disks". But we already have infrastructure for swap-spaces and dumping to them, even when the kernel is pretty hosed, so one would not have to start the project from scratch. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Adjustments to userland for a quieter startup (RC system)
> Okay, I am sorry, I mixed the general idea with detailed PR that aims
> just updating routing and devmatch parts with user selectable option
> not changing a defaults, thus my previous remarks are invalid and
> updated, I apologize! :-)
A goal of this PR was to flush out dialogue around whether there was a
universal noise level-adjusting knob in the RC system. [jlduran]'s more
ambitious PR, my PR, and the discussion to this post suggest "no." I think it's
probably right to generalize the discussion!
I also realize that this is a probably a controversial perspective. My
motivation here is ultimately service to the FreeBSD Laptop project. Windows
and OSX have conditioned many in the population of the FreeBSD-curious to
expect a lot less text on startup if things are going well.
To those who say "Yes, seeing the diagnostic data is why FreeBSD is so great,"
I say: In a server/device context, I'd not change anything (something my PR may
have flubbed in its implementation). ***But***, I contend that for FreeBSD to
thrive on a wider population of laptops and access a wider population of users,
some options (including such a noise knob for the RC system) ought be
available. The extent that [helloSystem] went to hide messages suggests an
unmet need.
[helloSystem]: https://hellosystem.github.io/docs/developer/boot.html#boot-mute
[jlduran]: https://github.com/jlduran/freebsd-src/pull/90/files
> * There is already `rc_info` that may be used?
> https://github.com/freebsd/freebsd-src/blob/50c962d773705f60d32c29f8e4bb2743ab55733b/libexec/rc/rc.conf#L29
I could see that and/or rc_debug replacing RC scripts' use of `echo`, though.
But (per "it's controversial"), we'd need future RC authors to adopt a notion
of "log level output" versus "printf/echo to the screen." My PR was modest in
its aims and didn't want to edit all the `echo`s. [jlduran] *did* dare more
bravely :) Although it seems (from the comments) that rc_debug has some complex
interactions with rc.subr that might make this option (my favorite thus far)
more complex than expected.
[rc.subr]:
https://github.com/freebsd/freebsd-src/blob/50c962d773705f60d32c29f8e4bb2743ab55733b/libexec/rc/rc.conf#L26
> * There is already `rc_startmsg` that may be used?
> https://github.com/freebsd/freebsd-src/blob/50c962d773705f60d32c29f8e4bb2743ab55733b/libexec/rc/rc.conf#L30
This was insufficient. It only squelched the "Starting ${name}" line :-/. e.g.
all the data e.g. about setting up a default route / interface output were
still logged.
> * If really necessary `_msgs` can be replaced with `_verbose` suffix?
> https://github.com/freebsd/freebsd-src/blob/50c962d773705f60d32c29f8e4bb2743ab55733b/libexec/rc/rc.conf#L568
Seems promising, but this would mean more conditional logic per each flag? I
think that's probably insufficiently general. `info` with its control in
`rc_info` per your earlier suggestion would seem the way to go.
> * I guess the idea is to silence the terminal? How many flags need to
> be put to silent instead just one? Why not just put a boot logo image
> if you really do not want to see the boot messages? It may provide
> expected user experience and will not impact diagnostic information
> that are usually useful :-)
Sadly boot_mute="YES" was insufficient as well. It only seems to mute
/kernel/-level diagnostics. Afterward, my screen was still full of
RC-originating content. And yes, suppose we /could/ do an overlay until the
login prompt -- I think that should be supported. It's what I _expected_
boot_mute=YES to do by default, frankly.
Perhaps the take-away should be:
* Existing interfaces are insufficient to let people easily tune their level of
RC output
* Resolve: Is this something that should be available?
* If so: resolve via log level, per-function verbosity suffixes, provide a
longer overlay bitmap duration option, or some other means
Thank you for your consideration,
Steven
Steven
Re: Adjustments to userland for a quieter startup (RC system)
On Sun, Feb 2, 2025 at 6:40 AM Sulev-Madis Silber < freebsd-current-freebsd-org...@ketas.si.pri.ee> wrote: > i'm thinking of what linux distros do. they are more common on laptops. i > haven't heard them hiding all and nor do i hear massive complaints about > "machine scribberish"? > systemd-journald captures all the logs and you use journalctl to access them. dmesg does most of the relevant things on fbsd. > also, when people, maybe not on fbsd but else where, complained that it > boots over a minute, how can it be. who even boots machines that much. that > was for servers. maybe laptops get booted nore often, esp. how the suspend > doesn't often work and nevermind to disk, that's not even implemented. so > people boot. also, is this recent or what. systems have booted for some > time since forever. ok this is about time, not messages. maybe times indeed > need blank screens with nice images > Linux systemd puts a UI up as quickly as possible while booting continues in the background. I'm not sure how trustworthy that is, TBH. -- brandon s allbery kf8nh allber...@gmail.com
