[SOLVED] Stuck on black screen after grub (Nvidia)

Ba7a7chy · 2024-02-28 21:36:07

Hi everyone.
After I upgraded today my system it seems I am having issues with starting my gnome desktop. It seems to be stuck somewhere before the greeter and after grub.

I believe it has something to do with Nvidia and the Kernel. When downgrading the Kernel or the Card I can login to the graphical environment (gnome shell) but it won't detect my Nvidia card.

I have tried linux-lts + nvidia-lts, but it hangs as well.
It also seems that executing `nvidia-smi` will freeze the terminal and eventually the session/shell.

I can login by adding `systemd.unit=multi-user.targrt` to my grub command and this allows me to drop to she'll which works fine.

Doing lspci | grep vga shows me Nvidia output.
I'm using Thinkpad with gforce GTX 4090, and it worked great until this very update.

Downgrading to the former Nvidia + Kernel doesn't seem to help.

I tried disabling kms, forcing kms, using nvidia-dkms, I don't really know what to try or check next

Last edited by Ba7a7chy (2024-02-29 13:19:37)

V1del · 2024-02-28 22:40:35

dkms (dynamic kernel module support) has nothing to do with kms (kernel mode setting) and it has absolutely no effect on this. KMS is https://wiki.archlinux.org/title/NVIDIA … de_setting which you're strongly suggested to setup as a kernel parameter to prevent a software driver from interfering.

On a boot creating the issue, from a TTY post the resulting link from

sudo journalctl -b | curl -F 'file=@-' 0x0.st

Last edited by V1del (2024-02-29 10:29:51)

Ba7a7chy · 2024-02-29 07:46:52

Uploaded: http://0x0.st/HRtm.txt

seth · 2024-02-29 08:19:08

Feb 29 08:14:52 ano kernel: [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
Feb 29 08:14:52 ano kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device

There's no obvious other issues, you'r enot booting a graphical.target.
So heed V1del's advice and enable https://wiki.archlinux.org/title/NVIDIA … de_setting - use the "nvidia_drm.modeset=1" kernel parameter (modprobe.conf won't do!), you can try fbdev=1 - but it had severe bugs at least in the previous version.

Ba7a7chy · 2024-02-29 09:27:30

Thanks Seth, I've put in the relevant parameters, now I get freeze/stuck even before, basically it's just hang while the text while starting the system, so I guess even earlier then before. Which makes sense as now it starts the driver earlier right?

Basically now it freezes even before the multi-user target so I can't have it enabled and log into shell at all.

I tried with and without `fbdev=1` but it doesn't seem to make any changes.

seth · 2024-02-29 09:53:19

D'oohhh.
Remove "nomodeset" (as well as the nomodeset parameters for the drivers you're not using)

Ba7a7chy · 2024-02-29 10:23:12

Removed and rebooted. My parameters now looks like loglevel=3 nvidia_drm.modeset=1 fbdev=1

Also reading around I've manually added the Nvidia modules to the mkinitcpio.conf which now has (nvidia nvidia_uvm nvidia_modeset nvidia_drm).

I've regenerated grub and initcpio.

Now it's stuck with only two lines showing
:: running early hook [udev]
Starting systemd-udevd version 255.4-1-arch

And then nothing. I think adding it to the actual modules made it get stuck even earlier, I'll try to see if the former tricks help to get into shell, if not I'll boot from USB and remove the modules and regenerate the images

Any ideas on how to proceed or what to try?

Edit:
Thanks the Linux gods it seems the trick with multi-user still works, so I am awaiting further ideas while reading around

Last edited by Ba7a7chy (2024-02-29 10:25:40)

seth · 2024-02-29 10:27:15

"fbdev=1" is nonsense anyway, it'd be "nvidia_drm.fbdev=1"
replacing those w/ "nomodeset systemd.unit=rescue.target" might still allow you to boot.

You previously also had "pci=realloc" - is that still there and why?

Edit: since you still can boot the multi-user.target, the problem is your graphical.target - which we haven't seen in any logs.
Post a journal that actually covers that.

Last edited by seth (2024-02-29 10:30:51)

Ba7a7chy · 2024-02-29 10:38:21

> "fbdev=1" is nonsense anyway, it'd be "nvidia_drm.fbdev=1"
replacing those w/ "nomodeset systemd.unit=rescue.target" might still allow you to boot.

My bad, fixed it and tried again, seems to doesn't effect the situation.

> You previously also had "pci=realloc" - is that still there and why?

Was a suggestion from another post, I've removed it already.

> Edit: since you still can boot the multi-user.target, the problem is your graphical.target - which we haven't seen in any logs.
Post a journal that actually covers that.

So, this is the issue. I guess for us to get there I can't use the multi-user target trick right? And if I don't use it I can't reach shell to get the journal posted.
Can I somehow login in the "bad way" where it gets stuck and then relogin "ok" and upload the older journal entry of the bad attempt? I'll google.

seth · 2024-02-29 10:59:35

From the bad boot, do not reboot with a hardware button (at least don't push the power button until the system shuts down)
You can then access the journal of the previous boot w/

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

Ba7a7chy · 2024-02-29 11:09:03

That's an issue, I can't quit the bad boot without pressing the power button until it dies
And it's a laptop so I can't pull out the power cord, and it has internal battery ahaha so...

I tried clicking other combinations but it seems fully frezzed.

Because I press the power button until it dies it seems the journal entry is corrupted/incomplete.

I can maybe try and ssh into it from another machine, let me see if that would work

Edit: sadly it seems that even SSH is stuck, it will accept the connection but won't let me log in...

The only thing that gets me as close as possible is using "ly" greeter and try to change a ty and get the journal then (if I choose any graphical option in LY it will get stuck as well)

Last edited by Ba7a7chy (2024-02-29 11:18:09)

Ba7a7chy · 2024-02-29 11:30:08

Can't believe it worked ahaha ok, we got it and it looks bad XD

http://0x0.st/HRxS.txt

Ba7a7chy · 2024-02-29 13:17:39

Ok! so now that I figured it's a driver induced kernel panic, I went ahead and used AUR package of an older nvidia-dkms. It works now fine and I can again login and have fun

I'll mark as solved, as I can log in, and the only real fix is waiting for Nvidia to release a new driver that will maybe fix whatever regression the last one added.

Arch Linux

#1 2024-02-28 21:36:07

[SOLVED] Stuck on black screen after grub (Nvidia)

#2 2024-02-28 22:40:35

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#3 2024-02-29 07:46:52

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#4 2024-02-29 08:19:08

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#5 2024-02-29 09:27:30

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#6 2024-02-29 09:53:19

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#7 2024-02-29 10:23:12

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#8 2024-02-29 10:27:15

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#9 2024-02-29 10:38:21

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#10 2024-02-29 10:59:35

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#11 2024-02-29 11:09:03

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#12 2024-02-29 11:30:08

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

#13 2024-02-29 13:17:39

Re: [SOLVED] Stuck on black screen after grub (Nvidia)

Board footer