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