1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1109077: sddm: does not start automatically after nvidia-driver ins

    From [email protected]@21:1/5 to All on Thu Jul 10 23:50:01 2025
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to All on Fri Jul 11 16:50:01 2025
    Update:

    After removing the `quiet` and `splash` boot parameters from the GRUB configuration, the issue no longer occurs — the graphical login starts
    as expected after reboot, without additionally delaying sddm start.

    This suggests that the root cause is not purely a systemd race
    condition, but also related to how early boot messaging and framebuffer ownership (e.g. Plymouth or silent boot) interact with SDDM and the
    proprietary NVIDIA driver. The problem appears to be timing-sensitive
    and possibly framebuffer-related, especially in live-build-installed
    systems with newer NVIDIA GPUs.

    Best regards!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)