From nobody Sat Mar 22 22:54:41 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZKvlZ0ZrQz5rN8h for ; Sat, 22 Mar 2025 22:54:50 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Received: from mail-24420.protonmail.ch (mail-24420.protonmail.ch [109.224.244.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZKvlX4CFlz46Sy for ; Sat, 22 Mar 2025 22:54:48 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevengharms.com; s=protonmail; t=1742684085; x=1742943285; bh=mmlLsv0IJVId7ppYh4ntHajlVvFoIdYZ76hc8VEGPfM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=nHpzu5eSEL7iWpU0bQIzMzRB1aDeJOrT98EzN46ebPOdhHGNACKedmGeYWIH5zQax A4+5Ng1PtFNe7d+Db+BPrDLh23+WQ7nfUSUF27p7SqmXwrMavTqYymwoXJ34aXRLZf gi7cGIO7GpxiOcWBqUAkqc0fXVolPMS4N4VVcw6A= Date: Sat, 22 Mar 2025 22:54:41 +0000 To: "Simon J. Gerraty" From: "Steven Harms (High-Security Mail)" Cc: Warner Losh , Emmanuel Vadot , "freebsd-current@freebsd.org" Subject: Re: Confused by boot_mute documentation, terminal systems, and goals Message-ID: In-Reply-To: <45025.1742665646@kaos.jnpr.net> References: <20250322080212.0fe0e090d8e942105e9feb65@bidouilliste.com> <45025.1742665646@kaos.jnpr.net> Feedback-ID: 16996530:user:proton X-Pm-Message-ID: 08091ac527f859a32271f0f35b75eb17a6f02e15 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29676, ipnet:109.224.244.0/22, country:GB] X-Rspamd-Queue-Id: 4ZKvlX4CFlz46Sy X-Spamd-Bar: ---- 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 a= nd I was indeed looking at a ball of knots. I'll tried Warner/Manus's suggestion re: boot_mute=3D"YES" and a specified splash=3D"" 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=3D"YES" splash=3D"/boot/images/freebsd-brand.png" loader_logo=3D"none" autoboot_delay=3D3 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-CURREN= T). So as of right now, I"m inclined to think that this set of configuration variable= s is=20 BROKEN. Please confirm my understanding, if you can. In efforts to move forward in the long-term perspective, I've taken the lib= erty of trying to synthesize your various data points into a strategy and to try th= e 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 thi= s purpose. Retain for historical true muting signal 1. Add variable to provide correct experience (just a stab): * `boot_overlay_expiry=3D"rc|consoleLogin|xdm|waylandDM"` # not sure abo= ut sensible values for X or Wayland Semantics in-depth: 1. `kern.vt.splash_cpu=3D0|1` * If 0, current default behavior. Show kernel and RC init output * If 1, current behavior with (improper) boot_mute=3DYES; display a gra= phical overlay; termination point to be expressed below 2. `splash=3Dstr` (pre-existing) * Previously unuseful for VT use, is documented as being correct per Man= u at present * Prune legacy in-kernel images to reduce confusion; use images in /boot= /images/ 3. `boot_overlay_expiry=3D..." would be NEW * `rc`: Disappear overlay after the VT subsystem moves from early-load t= o later-load. This is current status with (improper) boot_mute use * `consoleLogin`: System is intended to be used in native console. Disap= pear 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 graphic= al 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 reliabl= e. 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 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. >=20 > 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. >=20 > Doing something like that via rc alone would be "tricky". >=20 >=20 > Warner Losh imp@bsdimp.com wrote: >=20 > > 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.