Machine baselines and reboot timelines: first runs

Claim. A KVM sees only the screen. When a machine is healthy, reading it through the KVM, ssh and the network at the same time gives facts that no single channel gives, and a measured timeline of one reboot. Both were done on two machines with two different KVMs. They are first runs, not a success rate.

Method. Two machines that already had a KVM attached, in the operator's lab: a Mini PC running Ubuntu with UEFI firmware, watched through a GL.iNet Comet, and a Raspberry Pi 5 running Ubuntu, watched through a Sipeed NanoKVM Mini. For each, a baseline was collected while it was healthy: the KVM's screen and status, one ssh login as an ordinary user, and a network check that reads the ssh greeting without logging in. The ssh side sends its script on standard input, so nothing is written on the machine, and it needs no root. No serial numbers, keys or passwords are collected. Each baseline is stored privately and is not published.

What the baseline found.

• The channels agreed. On the Mini PC all 5 facts that two channels can both report matched (MAC address, IP address, screen size against the machine's display mode, whether the target sees the KVM keyboard, and its name on the login screen). On the Raspberry Pi all 3 that its channels could report matched. The NanoKVM cannot say whether the target sees its keyboard, so that one is recorded as unknown.
• ssh is an answer key for the screen. Comparing the words OCR read with what the machine says about itself found misreads on both machines. The Mini PC's console name tty1 was read as ttyi. On the Raspberry Pi the digit 0 was read as 8, 9 and @ in its login banner: 25.18 for 25.10, eth@ for eth0, mmcblk@p2 for mmcblk0p2. This describes one font on one screen. It is not an OCR accuracy figure.
• Firmware timing without a reboot. The Mini PC's own systemd-analyze reported 9.8 s of firmware time and 13.9 s in the boot loader before the kernel. The Raspberry Pi has no such split; it reported 4.2 s for the kernel and 25.4 s for userspace.

Reboot timelines. Each machine was rebooted once with Ctrl+Alt+Delete sent through its KVM, while the picture, ping, the ssh port, the ssh greeting and the screen's boot phase were watched on one clock. Seconds are counted from the moment the command was sent.

Two things the timelines show that the screen alone does not. The Comet kept reporting a picture through the whole dark firmware phase, so "the video drops" cannot be used to spot a reboot on that setup, while the NanoKVM's picture did drop, for 11.6 s. The screen's phases still gave the firmware window on the Mini PC: 9.5 s from the dark screen to the boot loader, close to the 9.8 s firmware time the machine reported. The two figures come from the same boot.

After the reboots.

• Both machines answered ssh and showed a login prompt again. A comparison with each baseline found no change in failed services or disks. The Mini PC's list of listening ports differed shortly after boot and matched on a later check; the cause was not examined. The Raspberry Pi's input devices were listed in a different order, which the tool then wrongly reported as a change (see below).
• Keys and mouse were checked against the target's own kernel again. The NanoKVM passed 17 of 17. The Comet passed 16 of 17 on the first run after the reboot: the first mouse move was not seen by the target. A second run passed 17 of 17. In between, the Comet reported keyboard and mouse as offline until the first input, although the target had listed both devices at boot. This is one observation of one reboot; the cause is unproven.

What the first runs got wrong in the tool, and the fixes.

• The probe cut its output at 6000 characters, which lost the network facts on a machine with many interfaces.
• On a machine running Kubernetes, virtual interfaces, loop devices and temporary ports change all the time and would have reported a healthy machine as changed. They are now left out.
• The answer key first missed console names and the OS version, and counted a cut-off word as a misread.
• The same input devices listed in a different order after a reboot were reported as a change.
• A reboot ends the logged-in session, so the screen read as a login prompt where the baseline had a shell prompt. That is expected after a reboot, not a fault.

Sample size. Two machines, two KVMs, one baseline and one reboot each. Three input checks after the reboots: one on the NanoKVM and two on the Comet.

Not tested. A reboot by the other methods (a power cut, a hard reset), a machine that fails to come back, a repair that used a baseline, any other KVM, any machine with a different firmware, and whether a baseline shortens a repair. That last one is the real test, and it needs a real failure.

Limits.

• One boot of each machine is not a repeatability figure. The timing will vary between boots.
• The screen phases come from OCR on a picture taken about every half second, so each time carries that much uncertainty.
• The Mini PC's firmware time and the screen's dark time were close here. Two numbers from one boot do not make a rule.
• This shows the method works on two machine types. It does not show that it speeds up a repair.