search

NiHaiden / aurora

The ultimate developer workstation, based on Bluefin with KDE, now incorporated into Bluefin.
https://getaurora.dev
Apache License 2.0
69 stars 1 forks source link

Boot - no login screen #20

Closed MLSci closed 2 months ago

MLSci commented 3 months ago

Describe the bug

Most of the time, booting won't proceed to the login screen, and gets stuck.

I'm able to switch to a different tty (e.g. tty2 or tty5), and from there, can confirm that SDDM is active (running) by using systemctl status sddm

Then I run systemctl restart sddm, and everything becomes normal - the login screen shows up.

This issue is deployment agnostic.

What did you expect to happen?

The login screen shows up without having to restart SDDM.

Output of rpm-ostree status

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/nihaiden/aurora-dx-nvidia:latest
                   Digest: sha256:4fbf62a4343e31723615124c3639dec6909c1af77b8d02d6dff9c270d91a0af0
                  Version: 39.20240403.0 (2024-04-03T22:58:02Z)
                   Pinned: yes

  ostree-image-signed:docker://ghcr.io/nihaiden/aurora-dx-nvidia:latest
                   Digest: sha256:ac6f67c1872cf3234bab686451c17f5d90418569e49363f3756d3fd0341da49c
                  Version: 39.20240402.0 (2024-04-03T07:53:15Z)

  ostree-image-signed:docker://ghcr.io/nihaiden/aurora-dx-nvidia:latest
                   Digest: sha256:8bf223c7481aaa5cd42b32c76a90a266bab04d97042aec955d0dcc6a16ca757e
                  Version: 39.20240401.0 (2024-04-02T08:04:51Z)

Extra information or context

I read somewhere this may happen when the GPU driver loads too slow. Is there any way to make GPU driver loads faster (e.g. prioritize it when scheduling the boot sequence)? Someone also mentioned to add delay to the loading of SDDM, although this will make the boot-up even slower. Edit: cross posted on https://pagure.io/fedora-kde/SIG/issue/491, https://github.com/sddm/sddm/issues/1905

NiHaiden commented 3 months ago

Hi, I pushed a fix that could possibly fix your issue. Could you please try updating to the latest version that I just built?

MLSci commented 3 months ago

Hi, I pushed a fix that could possibly fix your issue. Could you please try updating to the latest version that I just built?

OK, I'm updating now

MLSci commented 3 months ago

Updated. The issue persists. Let me know what logs I can provide you.

NiHaiden commented 3 months ago

Please try building a local initramfs to include the nvidia drivers with rpm-ostree initramfs --enable. You should have a /etc/dracut.conf.d/nvidia.conf file if you've updated to the latest image from 3 hours ago. If this does not work I will need the dmesg logs from you, probably. But let's try and pray 🫠 ( I hate nvidia)

MLSci commented 3 months ago

Ok, Initramfs regeneration is now enabled. I'm studying how to build a local initramfs.

My /etc/dracut.conf.d/ is empty though.

Attached is the dmesg logs. (not a fan of nvidia either, but AMD doesn't have real equivalent of CUDA..) dmesg_log.txt

NiHaiden commented 3 months ago

If your dracut.conf.d is empty please put a file named nvidia.conf in the folder with the following contents and build the initramfs with the command from above 

force_drivers+=" nvidia nvidia_modeset nvidia_uvm nvidia_drm "
MLSci commented 3 months ago

Added the nvidia.conf and updated rpm-ostree to the latest. Looks the issue is no longer observed. Thanks. Btw in the previous version, when the computer goes to sleep, it gets stuck in a state that only the motherboard is sleeping but not other hardware (cpu, gpu, etc.) I'll report back if it's present in the current ver. PS: cross-posting at https://pagure.io/fedora-kde/SIG/issue/491, https://github.com/sddm/sddm/issues/1905

Edit: is it better to leave Initramfs regenerate state at enabled, or re-disable it?