Comment 3 for bug 2033569

Found a solution.

There were two separate issues:

FIRST ISSUE

Apparently systemd likes to start up lightdm early, so early that on a reasonably fast system the GPU driver won't be ready in time ...

(I thought this was what systemd's dependency handling was for, but never mind.)

This seems to be a long-standing issue; it's neither multiseat- nor GPU-driver-specific. And considering this is just a budget AMD box, albeit a new one, it's going to bite more and more people in future.

My hypothesis re. why the first few boots with lightdm worked is that I was still in the middle of setting up the box, i.e. a lot changed from one boot to the next. Either one of those changes triggered the timing issue, or "clean" boots are faster per se.

The workarounds detailed in the Arch Wiki (https://wiki.archlinux.org/title/LightDM#LightDM_does_not_appear_or_monitor_only_displays_TTY_output) both work, to wit:

1) Add

[LightDM]
logind-check-graphical=true

in /etc/lightdm/lightdm.conf

- OR -

2) Enable early KMS by adding your GPU driver module to /etc/initramfs-tools/modules and running update-initramfs -k all -u.

SECOND ISSUE:
At some point while trying to fix this I deleted /var/lib/lightdm as well, which is lightdm's home directory. Since purging lightdm does not remove the lightdm user, reinstalling it will not (re)create this directory. Unfortunately the symptoms are the same as above--lightdm goes into a restart loop, then gives up.

Now, the second issue probably isn't a bug, though the postinst script could at least print a warning if the home directory isn't present and writeable, but the first one is, IMHO.