[PATCH v4] installer: suppress boot console status noise

[colbyt <colby@colbyt.com>]

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.
---
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.

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.
+  boot.kernelParams = [ "udev.log_priority=5" "quiet" "systemd.show_status=false" ];
   boot.initrd.verbose = false;
 
   boot.kernelPackages = pkgs.linuxPackages_latest;
-- 
2.55.0