Only Black Screen after login (after kernel/nvidia update)

General system Kernel, boot, graphics & hardware
21

It is dracut with grub. I don’t use systemd-boot.

Edit: You can’t use systemd-boot and boot on a snapshot as you can with grub i don’t think. :thinking:

22

When downgrading a kernel, I personally wouldn’t update/upgrade anything else until the kernel issue is fixed.

But you can. I don’t recommend it, though.

If you decide to ignore a specific package, then edit your pacman.conf.

sudo nano /etc/pacman.conf

Look for IgnorePkg and add the following:

IgnorePkg   = linux linux-headers
1 Like
23

I did because it had an update to btrfs. I only blocked linux and linux-headers for now.

1 Like
24

I don’t even know how all that works, that’s why I don’t use systemd-boot.

But what I am saying is that I believe the new EOS ISOs preselect systemd-boot. If a newbie just goes with the default (the current standard for EOS specifically), then they wouldn’t have GRUB.

1 Like
25

What is the underlying cause of this issue and is there any way to mitigate it in the future? It’s a little upsetting having a system break from a standard update. I get that sometimes packages need manual intervention, and this will be stated in arch news, and that the AUR can break things, but this was (from my understanding) a standard mainline update that just broke people’s systems.

Edit: Additionally, how will we know if/ when it is actually safe to update our systems? Are we just supposed to keep trying and reverting every time it breaks until it just happens to start working again?

26

So I have managed to get into my os by changing to x11 but its very basic, only 1 screen, half res. I cannot downgrade I think because my nvidia drivers are with dkms. so I tried to downgrade linux linux-headers nvidia-dkms nvidia-utils and got a dependancy for lib32-nvidia-utils so I added that too and tried
sudo downgrade nvidia-utils nvidia-dkms lib32-nvidia-utils
and I get
error: failed to commit transaction (conflicting files)
nvidia-utils: /usr/lib/libnvidia-egl-gbm.so exists in filesystem (owned by egl-gbm)
nvidia-utils: /usr/lib/libnvidia-egl-gbm.so.1 exists in filesystem (owned by egl-gbm)
nvidia-utils: /usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json exists in filesystem (owned by egl-gbm)
So now I am lost.

27

Try adding the package egl-gbm to the downgrade. I’m no expert, but that would be my next try if I were you. :slight_smile:

28

Yes that is correct.

1 Like
29

egl-gbm is a dependency of nvidia-utils

30

Same problem here, am able to get into (6,6,52-1-lts) okay.
Tried the downgrade nvidia from there and was still unable to get into (6.11.1.arch1-1)

Hope this gets resolved soon :confused:

1 Like
31

This is how you know.

Update:

Looking at the Arch forum and the bug reports (or lack of them), it seems this may be specific to nvidia only. So, maybe the kernel doesn’t need a downgrade?

Alas, holding off on updates is not a bad thing unless it is critical for your workflow. In fact, it can save you from updates like this. So, once a week or twice a month, even on a rolling release, is actually a good idea. :brain:

Another update:

People can follow these threads to see what happens:
Here: https://bbs.archlinux.org/viewtopic.php?id=299865
And here: https://bbs.archlinux.org/viewtopic.php?id=299870

1 Like
32

sudo downgrade linux linux-headers worked for me. I went back to 6.10.10.

1 Like
33

So i have fixed my install.

  1. use eos-shifttime and select a date before you updated. EOS will revert your system back to that state.
  2. run yay and update, but skip all core modules
  3. dkms autoinstall
    This basically got me up and running again, and after a little fettling everything seems to be good. I’ll try and update again in a weeks time.
    it seems to me to be a core update problem, as I am now running all other updates just fine, even nvidia 560 on KWIN (Wayland)
34

I have the same problem with my second computer, I will use x11 until the fix and postpone the update for the critical modules on my gaming computer.

35
36

I always advice use a lts on sidehand…

2 Likes
37

As @ringo said if Nvidia 100% recommending installing LTS kernel as fallback together with nvidia-lts or use nvidia-dkms instead of nvidia + nvidia-lts packages.

1 Like
38

With systemd-boot and nvidia dkms I need a bigger kernel partition than what I have right now to keep lts + latest, but I can confirm that adding nvidia_drm.fbdev=1 to the kernel parameters works for me (edit /etc/kernel/cmdline for systemd-boot and then run reinstall-kernels)

Arch wiki says this:

Additionally, with the driver version 545 and above, you can also set the experimental nvidia_drm.fbdev=1 parameter, which is required to tell the NVIDIA driver to provide its own framebuffer device instead of relying on efifb or vesafb, which do not work under simpledrm.

1 Like
39

thats great i thought about also… but was not sure about a relation to the update issue…

I just checked on my 3060 Nvidia GPU and i do not have such issue with sway nor plasma wayland sessions…
And i can see i use the same option there: nvidia_drm.fbdev=1

Graphics:
  Device-1: NVIDIA TU102 [GeForce RTX 2080 Ti Rev. A] vendor: Gigabyte

what about others?

40

2024-10-02_13-08
2024-10-02_13-08978×145 21.8 KB

not a Bug :wink: