Package: sddm
Version: 0.21.0
Severity: normal
Tags: upstream
On systems installed from a live-build-based Debian ISO (e.g., using
Calamares), SDDM does not start automatically after the proprietary
NVIDIA driver (nvidia-driver) has been installed manually. The same
applies to LightDM, but with slightly different symptoms.
Steps to reproduce:
1. Create a Debian 13 (Trixie) live system using live-build.
2. Install the system from the live environment (e.g., using Calamares).
3. Boot into the installed system and install the `nvidia-driver`
package.
4. Reboot.
Result:
- Neither `sddm` nor `lightdm` starts automatically.
- With LightDM, the system shows a TTY login screen.
- With SDDM, a black screen appears with no visible login.
- In case of sddm you cannot switch to TTY from blackscreen.
- After disabling the automatic service (`systemctl disable
sddm.service` or `lightdm.service`), the login managers can be started
manually from TTY with `systemctl start sddm` or `lightdm`, and then
function correctly.
- In the case of LightDM, the issue could be resolved by adding a
systemd override unit that waits for the NVIDIA kernel modules and
related services to be initialized (`nvidia-persistenced.service`,
`modprobe`, etc.).
- For SDDM, this workaround does *not* fix the issue.
Notes:
- This was observed on a system with an NVIDIA RTX 4080 Super using the
official Debian `nvidia-driver` package.
- It seems to be a race condition between GPU/driver initialization and
the display manager startup.
- The problem appears specific to systems installed from
`live-build`-based ISOs, and does not occur on standard Debian
installations.
- A more robust startup dependency setup (e.g., stronger `After=`
declarations or `ConditionPathExists=` for NVIDIA devices) may help
improve reliability, I think.
- Alternatively, documentation or integration advice for users
installing `nvidia-driver` on such systems could be added.
Open question:
Is there a fundamentally different systemd boot order or service
handling in live-build-installed systems compared to systems installed
using the official Debian Installer?
This issue only appears (after investigation with systems I got here) in
systems installed from live-build-based ISOs (e.g. via Calamares), not
in those installed via the standard Debian Installer. This might point
to subtle differences in default systemd targets, service dependencies,
or init sequence which affect GPU and display manager startup.(but, I
may be wrong - just thinking that it may be like this)
Thanks for your great work!