Well, Warner and Manu, it's been quite an education I've gotten myself into! If
anything, it confirms that my sense of C isn't as bad as I thought it was and I
was indeed looking at a ball of knots.
I'll tried Warner/Manus's suggestion re: boot_mute="YES" and a specified
splash="" value does not work in a VT tty on 14.1-RELEASE. Unfortunately, a
fresh build from `main` is giving me a kernel panic. I can confirm for Manu
that the splash.4 does say the right thing.
For completeness, my non-stock portion looks like:
boot_mute="YES"
splash="/boot/images/freebsd-brand.png"
loader_logo="none"
autoboot_delay=3
So the "limp-along" strategy (above) seems not to work. I'm happy to debug
further (or, if I get a working build of `main`, i can try with 15.0-CURRENT).
So as
of right now, I"m inclined to think that this set of configuration variables is
BROKEN. Please confirm my understanding, if you can.
In efforts to move forward in the long-term perspective, I've taken the liberty
of
trying to synthesize your various data points into a strategy and to try the
work around strategy.
I. The User Story
AS A: desktop/laptop/non-server FreeBSD User
I WANT: a way to specify use of an overlay image in a well-understood image
format (PNG, SVG, JPG?)
SO THAT:
* I can cover up diagnostic data that might be confusing/unsightly
* AND/OR brand my devices with employer/school/etc identity
* AND/OR have my first interaction with the system be
* vtty login (OR)
* display manager login
Provided the overlay lasts from POST to login (either graphical or console), we
can ignore the question of silencing RC scripts. Further chattiness can be
addressed via
`syslog.conf(5)`.
Now the question is, what configurations and parameters need to exist and
what's the migration strategy. I _think_ the way out of the abyss is:
II. Plan
1. Coordinate with vt maintainers (ofc.)
1. `boot_mute`: Should be documented as having been legacy but that its use
was inappropriate to trigger the overlay. Document as deprecated for this
purpose. Retain for historical true muting signal
1. Add variable to provide correct experience (just a stab):
* `boot_overlay_expiry="rc|consoleLogin|xdm|waylandDM"` # not sure about
sensible values for X or Wayland
Semantics in-depth:
1. `kern.vt.splash_cpu=0|1`
* If 0, current default behavior. Show kernel and RC init output
* If 1, current behavior with (improper) boot_mute=YES; display a graphical
overlay; termination point to be expressed below
2. `splash=str` (pre-existing)
* Previously unuseful for VT use, is documented as being correct per Manu at
present
* Prune legacy in-kernel images to reduce confusion; use images in
/boot/images/
3. `boot_overlay_expiry=..." would be NEW
* `rc`: Disappear overlay after the VT subsystem moves from early-load to
later-load. This is current status with (improper) boot_mute use
* `consoleLogin`: System is intended to be used in native console. Disappear
overlay to reveal the standard vtty login screen once it's ready
* xdm: Remove overlay as part of a handoff to X display manager. This is the
setting for my non-technical friends. Pair with a short autoboot_delay and
beastie_disable, this setting gets the computer from POST to a graphical
login without leaking any of the OS internals
* waylandDM: Same as above but with Wayland
There might be other variables that capture the signal better.
Thanks for all the insight, and I'm open to more :)
Steven
---
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 secure email.
On Saturday, March 22nd, 2025 at 1:47 PM, Simon J. Gerraty <s...@juniper.net>
wrote:
> FWIW I recently added logic to our local.rc.subr to
> redirect output to a console.log if desired (some platforms boot quicker
> with less output going to console). It does nothing for output from
> kernel modules loaded by rc, but greatly reduces output and has the
> major benefit that we can examine the "console" output after the fact.
> Which is much more useful than sending the output to /dev/null.
>
> The above is much easier done in our env as we have an initial rootfs
> which is an iso image, and run a preboot script which does things like
> mounting the real rootfs after fsck etc before running the real init(8).
> That preboot can thus take care of rotating and initializing console.log
> or disabiling it under various circumstances, and we set rc_config_xtra
> in local.rc.subr so we can tell when it is being read for first the so
> we can redirect output again for rc.
>
> Doing something like that via rc alone would be "tricky".
>
>
> Warner Losh i...@bsdimp.com wrote:
>
> > If you rarely want silence to the login prompt, we likely need to find
> > a way to redirect the console output to a second screen or
> > something. I thought we had a null console, but that appears to be
> > only in the boot loader. The rc output goes to the first console in
> > the list of all the consoles since that's what /dev/console is
> > connected to. One much wanted, often started but not finished project
> > is to actually make /dev/console connected to all the consoles
> > together.
