Next comparison: info logging through kmsg

The physical info/console comparison produced a fresh kernel and pre-exec init announcement, without systemd startup or login within 180 seconds. Lowering verbosity did not restore observed progress. This leaves the failing instruction unknown.

Read-only inspection of the exact selected systemd 261.2 archive uses the source pin and raw-file hashes in the preceding source audit. Pinned log.c maps kmsg at raw lines1514–1517, opens /dev/kmsg at129–139, and closes console on successful backend opening at323–332. Priority-tagged synchronous writes occur at606–619. Its per-emitter limit is200 messages/5 seconds at588. Opening/writing failure or an absent backend can fall back to console at337–340 and822–830. Selecting kmsg therefore does not prove console was unused or delivery succeeded.

The selected kernel printk source preserves the userspace severity in devkmsg_write; it may discard disabled/rate-limited records. INFO priority6 is eligible under the existing console threshold7, whose filter suppresses severity>=7. Eligibility is source proof, not runtime delivery. Raw references refer to files, not browser extraction numbering.

Change only rd.systemd.log_target=console to rd.systemd.log_target=kmsg, retaining info, all current p2/24h artifacts, source/config/Image/DT/initrd/init/root/masks/join/marker-free controls and existing verbosity. This produces352 argument and370 literal command bytes. Use typed begin-only --initrd-info-kmsg-logging, requiring both existing parent selectors and excluding debug/info-console. Save/restore it with old state defaulting false; reject aliases/types/conflicts before UART. No generic logging editor, tracing, masks, alternate PID1 or rebuild.

After independently reviewed source fixtures, actual artifact qualification and NEW protected recovery, run one180-second passive capture with exact loads/CRCs/printed/live arguments, full private logging and no candidate input on unknown readiness. Record independent recovery or explicit pending NEW reset. A changed boundary shows backend-selection sensitivity, not a blocked console call; silence cannot distinguish earlier setup, backend, filtering, dropped output or scheduling. Implementation and actual artifact qualification passed independent review. Physical delivery remains UNVERIFIED. Ordinary root/panel/glass task5b.5 stays open.

Read-only startup audit additionally finds INFO is the manager default, while main.c later selects journal-or-kmsg and reapplies commandline/environment settings. Explicit kmsg therefore is not fully equivalent to baseline. Console setup and separate status output also remain. If silent, the smallest next discriminator is one unchanged ordinary-baseline repeat, without any rd.systemd.log_* tokens, to check reproducibility before further interventions; that repeat has not been run.