base image: serial-getty@ttyS0 hangs ~90s on every boot (dev-ttyS0.device timeout)

Summary

Every microVM booted from images/base (ghcr.io/daax-dev/nanofuse/base:latest) hangs for ~90 seconds during guest boot waiting on dev-ttyS0.device, then times out and fails serial-getty@ttyS0.service:

[ TIME ] Timed out waiting for device dev-ttyS0.device - /dev/ttyS0.
[DEPEND] Dependency failed for serial-getty@ttyS0.service - Serial Getty on ttyS0.
[  OK  ] Reached target multi-user.target - Multi-User System.

multi-user.target is still reached and SSH/network work normally, so VMs are usable — but the serial console (Firecracker's primary out-of-band access path) is dead for the VM's entire lifetime, and every boot pays a ~90s console-readiness penalty.

Scope / reproducibility

• 100% reproducible on every boot, fresh or resumed.
• Independent of snapshot/resume: a fresh, never-snapshotted VM shows the identical timeout. (Discovered while validating issue #227; initially misattributed to the snapshot-resume path, then disproven with a fresh-boot control.)
• Independent of Firecracker version: identical on FC 1.7.0 and 1.16.1.

Environment

• Closed-loop KVM harness (dev/vagrant/, libvirt + nested KVM), Ubuntu 24.04 guest.
• Kernel cmdline includes console=ttyS0; Firecracker provides the 8250 UART.
• base image kernel 6.1.90 + Ubuntu 24.04 rootfs.

Likely cause (unconfirmed)

serial-getty@ttyS0.service BindsTo=/After= dev-ttyS0.device, and that device unit never activates — udev appears not to emit/process the add uevent that tags /dev/ttyS0 with SYSTEMD_WANTS in this minimal microVM kernel/udev setup. Candidate fixes to investigate (base-image side): ensure the serial UART is coldplugged (udev trigger), or decouple the getty from the device unit, or drop the enabled serial-getty@ttyS0 if serial-console login is not a product requirement.

Impact

• Does not block SSH-based use (daax-devtools coding-in-microVM works).
• Does break serial-console login and adds ~90s to console readiness on every boot.

Acceptance criteria

• A fresh microVM from images/base reaches multi-user.target with no dev-ttyS0.device timeout in the console log.
• serial-getty@ttyS0.service is either active (console login works) or intentionally removed, with the rationale recorded.
• Verified on the dev/vagrant/ real-KVM harness.

Filed from real-KVM closed-loop testing. Root-cause diagnosis is a hypothesis; validate against the guest udev/systemd behavior before fixing.

Start with the images/base guest and inspect its udev and systemd behavior around dev-ttyS0.device and serial-getty@ttyS0.service. Reproduce a fresh boot using the dev/vagrant/ real-KVM harness, then verify the console log and service state. Done means no device timeout, an intentional working or removed serial getty with rationale, and verification in the harness.