Re: [PATCH v4] installer: suppress boot console status noise

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 5574 bytes --]

colbyt <colby@colbyt.com> writes:

> Add quiet and systemd.show_status=false to the installer's kernel
> parameters. These are the two parameters that measurably change what
> reaches the video console; a leave-one-out boot over the v1
> parameter set (frame captures of the virtual console per configuration)
> showed the rest were redundant or inert. v1's loglevel=3 in particular
> never took effect: boot.consoleLogLevel appends loglevel=2 after it and
> last-wins. The QEMU runner's serial forwarding is left alone.
> ---

Thanks for paring it down.  To accept patches I need them to have a
Signed-off-by line to indicate the submitter has accepted the Developer
Certificate of Origin and taken responsibility for the code being
submitted[1].

[1]: https://spectrum-os.org/doc/contributing

A couple of other things too:

 • The text above the "--- "is what gets recorded in the commit log.
   It should stand on its own, without referring to previous versions of
   the same patch, to make it easier to understand when looking back
   from the future.

> v4/v3: no code change — drop a stray in-body From line that would have
> misattributed authorship when applied. (v2 changes below.)
>
> Answers to your review questions - from one build of
> the installer, thirteen boots differing only in -append, one video-
> console frame capture per second per boot:
>
> Why loglevel=3? It turns out it never took effect: boot.consoleLogLevel
> (mkDefault 2 in the same file) appends loglevel=2 AFTER the explicit
> loglevel=3, and last-wins — so the shipped v1 installer actually ran at
> console loglevel 2, and the "3" did nothing anyway. For the general
> question: the boot-time kernel spew is all KERN_INFO, so quiet alone
> (console loglevel 4) already suppressed it in every run; loglevel=4 and
> =3 were indistinguishable on this platform, =5 admitted two early
> warnings.
>
> Are all six needed at once? No — leave-one-out showed:
> - quiet: handles the kernel messages and the stage-1 script.
> - systemd.show_status=false: handles PID 1's status lines
>   (proven by the control run below).
> - rd.systemd.show_status / rd.udev.log_level: inert — stage-1 is the
>   script initrd; nothing consumes them.
> - udev.log_level=3: no observable console difference in any run; udev
>   logs to the journal, and the udev-era text in the baseline was kernel
>   printk.
>
> The run-vm.nix change is gone from v2 — agreed the serial forwarding
> divergence is useful in dev, and serial output never factored into the
> flicker measurements anyway.
>
> One finding you may care about beyond this patch: with the full v1
> parameter set, ~5-8s of systemd status text still reached the video
> console. A control run with plymouth.enable=0 was perfectly black —
> so systemd.show_status=false IS honored — which isolates the cause:
> when plymouthd starts before the DRM device exists (virtio-gpu binds
> mid-boot in the VM; any hardware with a slow GPU probe behaves the
> same), it falls back to details mode and force-enables PID 1 status
> output, overriding systemd.show_status=false. So true flicker-free boot
> on slow-probe machines is a plymouth-fallback issue; happy to dig at that separately if it's of interest sometime.

Interesting.  I guess we need to delay the start of Plymouth until a DRM
device exists, then?

It's probably not worth looking more into that now, because it sounds
like we will move towards installing from Spectrum rather than having a
separate NixOS installer system.  The way to delay Plymouth starting
would be different between the two systems, so it's probably not
worthwhile (from a Spectrum point of view) to spend time on it before
then.  (If you're motivated by fixing Plymouth on NixOS, though, then it
could be worthwhile, because I imagine other NixOS systems would have
the same problem.)

(In contrast, the work on finding the right kernel command line things is
likely to carry over when we integrate Plymouth into Spectrum, at least
for the non-systemd ones.)

> I kept the evidence for review later (frame PNGs + serial logs per configuration) and can share if needed.
>
>  spectrum/release/installer/configuration.nix | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/release/installer/configuration.nix b/release/installer/configuration.nix
> index 3f9ef247..c5ec1af2 100644
> --- a/release/installer/configuration.nix
> +++ b/release/installer/configuration.nix
> @@ -11,7 +11,11 @@ in
>    imports = [ (modulesPath + "/profiles/all-hardware.nix") ];
>  
>    boot.consoleLogLevel = lib.mkDefault 2;
> -  boot.kernelParams = [ "udev.log_priority=5" ];
> +  # quiet raises the kernel console threshold past the INFO chatter that
> +  # reaches the video console during boot (and silences the stage-1 script);
> +  # systemd.show_status=false stops PID 1's status lines. Every other
> +  # parameter from v1 measured as redundant or inert — see the cover letter.

Comments shouldn't refer to information in the patches/commits that
introduce them, so that readers don't have to dig those out to
understand them.

> +  boot.kernelParams = [ "udev.log_priority=5" "quiet" "systemd.show_status=false" ];

Do we definitely want systemd.show_status=false?  According to
systemd(1), the default behaviour if "quiet" is on the command line is
for systemd to only show errors.  Setting systemd.show_status=false also
hides errors, which sounds like it would be undesirable.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]