SDDM sometimes fails to start and requires a hard reset

Ok, I am finally free so it's time for some updates.
I managed to uninstall the xf86-video-intel driver - what was causing the issue with being unable to find a display was the 20-intel.conf file I'd put into /etc/X11/xorg.conf.d/ in a different attempt to see what was up with Librewolf not having proper hardware acceleration (that was actually solved by following this article on Arch Wiki ). Unfortunately, it seems my specialty lies in causing problems to fix other problems that don't actually fix the other problem LOL, but it's all part of learning. ;D
After removing that xorg conf file, I can boot again.

As for adding i915.preliminary_hw_support=1 i915.modeset=1 to the GRUB entry after uninstalling xf86-video-intel, it didn't work so that's been reverted.
(btw, is it just me or is editing the GRUB entries in the GRUB menu by pressing E really laggy? Could just be another HiDPI problem, unfortunately I'm no stranger to those and there's never a shortage of them either.)

I've set the delay on sddm-plymouth to 5 seconds to see if any freezing will happen in the future, but it seems it's now really good at delaying itself beyond that to wait for other required modules to start. Apparently, so far, SDDM hasn't failed since the 23rd of November, when that last sddm.log was modified. If SDDM doesn't fail within the next 2 weeks, I'll call this a success. :slight_smile:

The recent NVIDIA updates could have an impact on this, so let's see how it goes ^^


Update after 21 days

I almost forgot about this thread, whoops haha :sweat_smile:

The issue has stopped happening since my last post, and it's unclear what exactly caused it to stop happening (may have been removing the unneeded modules from raminitfs which were there by default and only using i915, adding nvidia_drm.modeset=1 to the kernel parameters or the recent Nvidia update), but I'm glad this issue has been eradicated. I've marked petsam's post as the solution since following the instructions resolved the issue.

From the text output on Plymouth boot screen, any hangs now during boot are from loading kernel modules after 5 seconds... but I solved that by switching kernels. Eventually, that also stopped happening ¯\_(ツ)_/¯ so idk.
Just wait, maybe the boot problems will start again at the least convenient time. My laptop is the opposite of my car, which knows to break down when it's the best time and place to break down... :rofl:


tl;dr

If you've encountered this thread since you're looking for answers to the same thing, here's the general rundown of things you should try, including those mentioned in petsam's post:

  • Remove unneeded modules from your mkinitpcio.conf. Currently, my modules list includes intel_agp in addition to i915 to take advantage of Intel hardware, following this guide. My Garuda came with modules that I didn't need by default, such as amdgpu and radeon.
  • Use a different kernel - hopefully this one solves your issue, as it's the most simple of all of them. From here on out, it's really a game of whack-a-mole.
  • If you use nvidia-prime, add nvidia_drm.modeset=1 as a kernel parameter. If you want this to be a permanent thing and not need to edit with every boot, edit /etc/default/grub.conf, then run sudo update-grub.
  • If SDDM is loading before your graphics modules have a chance to load, add a delay to the start of SDDM by editing sddm-plymouth.service with sudo systemctl edit sddm-plymouth, and add (with 5 being 5 seconds, but you might need 30 seconds if it takes that long for your module to load):
[Service]
ExecStartPre=/bin/sleep 5

Keep in mind that if you have Plymouth, you need to edit sddm-plymouth.service, not sddm.service. If you edit sddm only, it won't have any effect because it won't be used. (Trust me, I tried... lmao)

  • systemctl set-default graphical.target, although tbf without this, SDDM will refuse to run anyways.
  • Run a pacdiff and check whether you have any crucial pending changes to make. I got a lot of .pacnew files since my last post, and some of them may have also been instrumental to addressing the issue.

Hope this helps anyone out there - it's an infuriating issue to deal with ^^;