Reported: installed from the ISO, files present, but the kiosk setup
never appeared on first boot.
Cause: kiosk-firstboot.service had After=cloud-final.service, and on 26.04
cloud-final.service is After=multi-user.target - while multi-user.target,
which wants kiosk-firstboot, is implicitly After= it. An ordering cycle;
systemd breaks it at boot by deleting a job, and kiosk-firstboot's was
the one to go. systemd-analyze verify against the 26.04.1 ISO's own units
reproduces it:
Found ordering cycle: kiosk-firstboot.service/start after
cloud-final.service/start after multi-user.target/start - after
kiosk-firstboot.service
- Drop After=cloud-final.service. The script's `cloud-init status --wait`
goes too: cloud-final waits for multi-user.target, which waits for this
service - it would deadlock. DPkg::Lock::Timeout already covers what it
was guarding against (dpkg lock contention).
- Drop Conflicts=getty@tty1.service: getty.target pulls getty@tty1 into
the same boot transaction, and a conflict between two wanted jobs is
also resolved by dropping one. Before=getty@tty1 alone keeps tty1's
login prompt waiting until this oneshot finishes.
Verified: systemd-analyze verify of kiosk-firstboot + multi-user.target +
cloud-final + cloud-init.target + getty@tty1 + graphical.target in the
26.04.1 server filesystem - old unit reports the cycle, fixed unit is
clean.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cjz8a58eB5P9sUweqd3NHm
Claude
b479b68219