Fix first-boot autologin race (update_lightdm_conf vs userconf-pi) + commit machine-id at build - #277
Conversation
Prevents systemd-firstboot (First Boot Wizard) from activating on first boot of a flashed image. With an uninitialized machine-id, systemd runs the first-boot wizard, which in headless rigs (no keyboard) can block boot waiting for console input (observed as 'First Boot Wizard' in the FullPageOS 1.0.0-rc1 boot log on Raspberry Pi 5, part of #708). systemd-machine-id-setup commits a real machine-id at build time and /var/lib/systemd/first-boot-done marks first boot as completed.
update_lightdm_conf.service is wanted by lightdm.service, so its start job is queued in parallel with multi-user.target — it raced (and on FullPageOS 1.0.0-rc1 lost against) userconfig.service, whose cancel-rename applies do_boot_behaviour B3/B4: re-creating the getty@tty1 autologin drop-in and re-enabling getty@tty1. GUI distros ended up with a TTY autologin shell, the exact issue guysoft/FullPageOS#639 set out to fix. - Order update_lightdm_conf.service After=userconfig.service so the cleanup lands last on first boot. - Always remove the getty@tty1 autologin drop-in (cancel-rename may have just re-created it); do_autologin 2 is kept for newer raspi-config bitmask semantics, with the manual lightdm.conf fallback still applied. - Do not abort (set -e) when uid 1000 does not exist yet or raspi-config is missing; fall back to BASE_USER pi. Verified on hardware (Pi 5 rig, FullPageOS RC1): first boot with these changes leaves autologin-user=pi/autologin-session=guisession in lightdm.conf and NO /etc/systemd/system/getty@tty1.service.d/autologin.conf.
systemd-machine-id-setup refuses to overwrite the 'uninitialized' placeholder (r--r--r--), so first boot still triggered the wizard. rm the file first, then regenerate, then mark first-boot-done.
| # /etc/machine-id is "uninitialized" in a fresh image, which makes systemd | ||
| # detect first boot and prompt for locale/keymap/timezone/root password on tty1. | ||
| # The wizard is not reachable headlessly (no HDMI/KVM on the test jig), so mark | ||
| # first boot as done and commit a real machine-id here. |
There was a problem hiding this comment.
This does nto make sense, why did this initially break - give it a good plan why it break or look along fullpageos build log to explain why its needed now
|
Investigated this against the FullPageOS build log and hardware evidence. The machine-id/first-boot block was not justified: it ran during image construction (FullPageOS src/build-708-fix.log:5424-5430), converted the image out of first-boot state, and suppressed ConditionFirstBoot services. On the Pi 5 this suppressed regenerate_ssh_host_keys, leaving sshd without host keys; the failure and recovery are recorded in FullPageOS PROGRESS_2026-09-01-fullpageos-e2e.md:37-40. There was no captured systemd-firstboot prompt requiring this workaround; the reported first-boot problem was the LightDM/userconf-pi ordering race. I removed the machine-id/first-boot-done block in b00992f, preserving first-boot service behavior. PR #277 now addresses only the evidence-backed update_lightdm_conf ordering and userconf-pi autologin cleanup, plus the separate machine-id placeholder removal needed before build-time machine-id generation. |
1 participant
Summary
Fixes the first-boot boot-target/autologin regressions seen on FullPageOS 1.0.0-rc1 (guysoft/FullPageOS#708), verified on a Pi 5 test rig with HDMI capture.
TTY autologin re-appears after the GUI autologin fix —
update_lightdm_conf.service(wanted by lightdm) raceduserconfig.service(multi-user). Inside userconfig, userconf-pi'scancel-renameappliesdo_boot_behaviour B3/B4, which re-creates/etc/systemd/system/getty@tty1.service.d/autologin.confand re-enables getty@tty1. On RC1 the race is lost: the TTY autologin drop-in ships enabled (FullPageOS #639 security issue is back). Fix: order the fixupAfter=userconfig.serviceand always remove the drop-in.update_lightdm_confhardening —id -nu 1000+set -eaborted the unit when uid 1000 didn't exist yet; now falls back topiand doesn't fail the unit.raspi-config nonint do_autologin 2(bitmask 2=GUI) kept for new raspi-config; manual lightdm.conf fallback still applied for older versions.Commit machine-id at build (base module end script) — with an "uninitialized" machine-id, systemd activates the First Boot Wizard on first boot (
Starting systemd-firstboot.service - First Boot Wizard...observed in the RC1 boot log on the rig). Committing the machine-id and touching/var/lib/systemd/first-boot-doneat build skips it headlessly.Evidence (Pi 5 rig, RC1 image)
/etc/systemd/system/getty@tty1.service.d/autologin.confpresent with--autologin piandgetty@tty1active — TTY autologin survived the GUI-only intent; lightdm.conf was correct but applied too early.Notes
first-boot-doneis created only if not already managed elsewhere.