This system has no display manager. No login screen, no graphical prompt, nothing that starts automatically when the machine boots. KDE Plasma starts from a plain console login, by running a script by hand — and that script exists at all only because the first time someone tried starting Plasma manually, it failed with nothing to show for it.
What's actually missing
build/stage2/ in this project has a directory for sddm-kcm — the System Settings module that lets a running desktop configure SDDM's appearance and behavior — but no directory for SDDM itself. The configuration panel for a display manager exists; the display manager it configures was never built. That's not an oversight discovered later — Plasma sessions on this build have always started from a bare console login, by directly invoking startplasma-wayland.
The failure that had nothing to investigate
The first real attempt at this failed silently: the desktop simply didn't start, and there was nothing captured anywhere to explain why. Running a command by hand at a console and having it fail leaves you with whatever scrolled past on that same console, if anything — no log file, no separate place to look, nothing preserved once the terminal moves on. That's the actual problem start-plasma-logged was written to solve, not the graphical desktop itself: a wrapper script that runs the real Plasma-launch command but redirects every kind of diagnostic information that might matter into a timestamped directory first — environment variables, active login sessions, kernel messages before and after the attempt, the full startup log — so a failed attempt leaves a complete record instead of a blank terminal and a guess.
Why the desktop needed help creating its own runtime directory
One specific piece of that wrapper exists because of a second, separate gap: this system's systemd was originally built without PAM session support, so logging in never registers a session with systemd-logind, and XDG_RUNTIME_DIR — the per-user directory a Wayland compositor requires to even create its display socket — never gets created automatically. start-plasma-logged checks for it directly and, if it's missing, creates and permission-locks it by hand before attempting to start anything graphical — manually replicating, for one script's purposes, exactly what a working PAM session would otherwise do automatically at login. That gap has since been fixed at its actual source — systemd was rebuilt with PAM support once Linux-PAM existed to build against — but the manual fallback in the launch script stays in place regardless, since starting a desktop from a bare console login was never going to have a login-manager-driven PAM session in the first place, fixed systemd or not.
A deliberate gap, not a temporary one
Nothing about this setup treats the missing display manager as a step that still needs finishing. The logging wrapper isn't a stopgap on the way to installing SDDM properly later — it's the actual, ongoing way this system starts its desktop, matching a build that has no other automatic login flow to hand off to. A display manager coordinates handing a graphical session to whichever user logs in through it; a system with no other users and no reason to present a graphical login screen at all doesn't need that coordination layer, only a reliable way to start the session by hand and, when it doesn't come up, actually find out why.