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!

Reply via email to