Recent update breaks my system

i did but LTS kernel gives me a huge wait time on loading and ultimately nothing happens, i had to reboot to a snapshot as the update is still giving a black screen on reboot.

I think now you could try the sudo dkms autoinstall (if I'm not mistaking the one you tried before was after the rollback, whan only 5.17.1 was available).
Anyway, in my opinion, what you need is to clean up your dkms for the nvidia part.
I'd do something like the following

sudo pacman -R nvidia-470xx-dkms
sudo pacman -Rns $(pacman -Qqtd)
sudo rm -rf  /var/lib/dkms/nvidia
sudo pacman -Syu nvidia-470xx-dkms
1 Like

you want me to do this before or after the update?
Because i rolled back...

I'd do it after, booting to a tty.
It could be that there is something wrong inside the system also "before", but I think you have to face the problem after.

So i am running all these commands after running garuda-update and not sudo pacman -Syu
Another question should there be this kernel parameter on grub cfg
quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 loglevel=3

Either is fine. garuda-update is always the best choice.
When you are in the condition that, with the new zen kernel version 5.17.5 you cannot boot.

1 Like

I would suggest using dkms manually to see current status and run actions one by one to get better info.
Read info
https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support

1 Like

Problem ended up being an Xorg config file that they created months ago that only started making problems in a recent update of some package. Nothing about dkms or anything like that.
Lesson learned: let Xorg do its thing and don't tell it what to do with config files

4 Likes

Thanks for the help, it was a mistake on my end since nvidia drivers were broken already and should'nt have done that while blindly following a arch wiki article.

Think you could quickly go over how you debugged that this was the problem btw? Might be useful for others who have similar issues to know where to look and error messages etc

Well, they said there they had a black screen. Tried the old and trusted ctrl+alt+f2 to get into a TTY, worked no problem. Alright, that narrows the issue down to Xorg. Viewed the Xorg log file, saw it used some weird default resolution instead of a standard monitor resolution. Told @Partha2003 to try and log in while the screen is black cause it seems like sddm is still loading just fine. Huzzah! Logged in with screen output. At this point I was very suspicious of Xorg, so I ran glxinfo -B, which told me it was using the NVIDIA GPU by default, which is not at all Garuda Linux's default config. So I looked at the config folder and would you look at that? A custom Xorg config file in xorg.conf.d configured to do something with NVIDIA prime. Deleted that file, so Garuda's default prime configuration can take over and voilà, issue is fixed.

4 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.