Journalctl shows:
Failed to start gdm-password verification for user: Gio.ioerrorenum: the connection is closed.
Everything boots fine, showing the Gnome login screen, but once I enter my password the screen briefly goes dark and then gets back to the login screen. At that point I cannot re-enter my password, and that’s it.
Last time this happened I reinstalled Fedora. But since this is now the second time, I would like to find an actual solution to the problem.
What I already tried:
- sudo dnf update –refresh (and reboot)
- tried Gnome Classic login
- as per AI instruction: disable gdm and use lightdm, to no avail
- booted with an older kernel
I’m at a loss, especially since I did not do anything system related yesterday. So I’m currently sentenced to using Win11 (and it hurts! 
)
Thanks for any advice.
PS: I use the rpm fusion nvidia drivers if that matters.
This is the second post related to GDM today.
Can you go to another tty at login, with ctrl+alt+f3 ?
If so, can you login to Gnome manually with startx
or
gnome-shell --wayland
?
Interesting: startx is working, but not gnome-shell –wayland. It throws:
/dev/dri/card1 does not support EGL.uffer sharing
I have an AMD iGPU that I have disabled at boot time, so /dev/dri/card1 looks to be my main NVIDIA RTX 4080 card. nvidia-smi returns a valid result, so the driver itself seems ok.
Shall I start removing and reinstalling the nvidia drivers? Not sure where to start.
Now that I think of it: I saw an upgrade of mutter a few days ago, and I remember there was an issue with an update some months ago requiring to freeze to an older version. Will try to downgrade it tonight.
1 Like
The other user who was having an issue with the gnome login basically hanging on him and presenting a black screen found some respite by passing the running kernel the nomodeset parameter (hit e on the grub screen, edit the line with vmlinuz on it and stick that parameter at the end. It’s a one shot deal - will revert to normal upon reboot.
Give that a try - if it helps, then the issue seems to be passing the mode-setting on to the nvidia drivers being suboptimal… and causing the nvidia drivers a bit of an issue.
nomodeset delays that mode-setting by the kernel and lets the nv drivers sort themselves out.
If it helps your situation, then we can make that parameter permanent until a fix is produced either in the kernel or in the nv drivers… at which point we can remove it permanently
Give it a try - can’t hurt any more than you’re currently experiencing, and if it makes no difference then it removes itself, and you’ve lost nothing other than a reboot.
1 Like
If you installed Nvidia drivers via RPM Fusion there should be no need to reinstall them.
Trying a downgrade, and also Steve’s suggestions are also good.
What I did in the mean time:
- Downgrade mutter → did nothing
- Removed/reinstalled nvidia driver (rpm fusion) → did nothing
- Checked grub2 config and noticed that it was reset: added nomodeset and modprobe.blacklist=amdgpu again (I always have to do this with Fedora or I will have all kinds of display/gpu issues) → no joy either
Pesky little problem.
Let’s see what is actually being used and what’s being loaded - post the output from an inxi -Fzxx.
Did you actually boot by adding the nomodeset parameter to a kernel by hand?
Simply adding it to config file won’t trigger a rebuild and thus start the kernel with that parameter. (I think!)
It’ll add it for future kernels of course… At least not unless grub has become a lot smarter these days.
I added nomodeset and the blacklist through sudo nano /etc/default/grub and then ran grub2-mkconfig -o, so yes, it is actually written to the grub config (I verified). I am definitely not a linux specialist, but I know the basic stuff
inxi -Fzxx: (looks like my nvidia card is used):
Graphics:
Device-1: NVIDIA AD103 [GeForce RTX 4080] vendor: Micro-Star MSI
driver: nvidia v: 580.82.09 arch: Lovelace pcie: speed: 2.5 GT/s lanes: 16
ports: active: none off: DP-1,HDMI-A-1 empty: DP-2,DP-3 bus-ID: 01:00.0
chip-ID: 10de:2704
Device-2: Advanced Micro Devices [AMD/ATI] Raphael vendor: ASRock
driver: N/A arch: RDNA-2 pcie: speed: 16 GT/s lanes: 16 bus-ID: 14:00.0
chip-ID: 1002:164e
Display: unspecified server: X.Org v: 21.1.18 with: Xwayland v: 24.1.8
compositor: gnome-shell driver: X: loaded: nvidia unloaded: modesetting
alternate: fbdev,nouveau,nv,vesa gpu: nv_platform,nvidia,nvidia-nvswitch
display-ID: :0 screens: 1
So the conclusion so far is that it really is some EGL buffering sharing issue. Whatever that may mean (Chinese to me at least).
No worries - as you didn’t specifically mention you’d rebuilt grub then I couldn’t assume you knew you had to.
1 Like
The full output when trying to run gnome-shell –wayland:
libmutter-Message: 17:50:03.276: Running GNOME Shell (using mutter 48.5) as a Wayland display server
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
libmutter-Message: 17:50:03.312: Thread 'KMS thread' will be using high priority scheduling
libmutter-Message: 17:50:03.312: Device '/dev/dri/card1' prefers shadow buffer
libmutter-Message: 17:50:03.548: Added device '/dev/dri/card1' (nvidia-drm) using atomic mode setting.
libmutter-Message: 17:50:03.549: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: No EGL display
libmutter-Message: 17:50:03.549: Created gbm renderer for '/dev/dri/card1'
libmutter-Message: 17:50:03.549: Boot VGA GPU /dev/dri/card1 selected as primary
Failed to setup: The GPU /dev/dri/card1 chosen as primary is not supported by EGL.
Do you get the same issue if you enable the amd gpu in your CPU? Tried re-enabling it and allowing it to load the amdgpu driver?
Enabling the iGPU opens up its own issues, which is why I have it disabled in the first place.
But for troubleshooting purposes I did 2 things:
- Enabled the iGPU, disconnected my displays from the nvidia card, and connected one display to the iGPU → in that case the login works fine
- Enabled the iGPU, but kept my display(s) connected to the nvidia card → same issue again
So it seems to be related to the nvidia card. Which is strange because the 580.82.09 driver was installed somewhere in September or so.
It feels like some hardware number randomly changed, somewhere, and now it’s pointing to a wrong or non-existing device. Though there’s no log so far that shows this.
Yep - that what kinda what I was expecting - the log you posted an hour ago shows the following:
libmutter-Message: 17:50:03.312: Device '/dev/dri/card1' prefers shadow buffer
libmutter-Message: 17:50:03.548: Added device '/dev/dri/card1' (nvidia-drm) using atomic mode setting.
/dev/dri/card1 is the only device available, as you’ve disabled the AMD igpu.
libmutter-Message: 17:50:03.549: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: No EGL display
libmutter-Message: 17:50:03.549: Boot VGA GPU /dev/dri/card1 selected as primary
Failed to setup: The GPU /dev/dri/card1 chosen as primary is not supported by EGL.
I only had one card available, and its drivers indicate that it doesn’t support EGL. No EGL, no wayland rendering, no screen.
Do you have nvidia-drm.modeset=1 in your kernel parameters already? If not, try kicking the tyres on a boot with that specified.
Yes.
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-9489342c-38d3-4370-9120-9d52f9ab437b rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau,amdgpu nvidia-drm.modeset=1"
I’m going to ponder this some more. If nothing else it’ll be a complete reinstall.
Roll back to the previous nvidia driver - I presume it didn’t have any of these issues?
Actually within the grub menu the line that begins with linux= would be the one to edit. That leads to the kernel parameters from grub.
The default contains only rhgb quiet and installing the nvidia drivers adds 2 parameters rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core