Gdm blank after update, but can still login with password without visible prompt

After an update around the end of May, I restarted and found the GDM greeter screen to be blank. It has the same gray background color as before and my mouse cursor works, but nothing else appears. Interestingly, I can still login by performing these steps:

  1. Access a tty (Ctrl+Alt+F6).
  2. Return to the display manager (Ctrl+Alt+F2), which remains blank as before.
  3. Press Enter, type in my password, press Enter.

Two things to note: first, I wasn’t able to login without first going to the tty. Perhaps in the process I managed to select myself as the user. I can’t say, since I can’t see anything. Second, once it begins to login, I do see my user card and filled-in password field for a split second. It shows at a much lower resolution than is typical. So I wonder whether something is awry with the resolution that prevents that portion from showing?

Otherwise, no problems with my system. I have been using Wayland fine with nvidia proprietary drivers.

My main hardware:
Gigabyte Aorus B550i
AMD 5600X
Nvidia 3080ti

Thanks for reading and for any suggestions. Should I take this to a Gnome-specific support forum?

You seem to be using an RTX 3080 Ti nvidia GPU.
Have you installed the nvidia drivers from rpmfusion?
What is the output of cat /proc/cmdline?
What is the output of dnf list installed '*nvidia*'

I had similar symptoms when I upgraded to F38 from 37 and had to tweak the kernel command line to fix it.

Hey, thanks for your reply. I do have the proprietary drivers installed. Here is the output for those two commands.

For the contents of /proc/cmdline:
BOOT_IMAGE=(hd1,gpt2)/vmlinuz-6.3.5-200.fc38.x86_64 root=UUID=b97888fd-3c86-420
│ 5-9ab1-0ea9174e22e3 ro rootflags=subvol=root00 rd.driver.blacklist=nouveau modp
│ robe.blacklist=nouveau rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklis
│ t=nouveau

Installed packages with nvidia:
akmod-nvidia.x86_64                  3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
                                     3:530.41.03-1.fc38 @@commandline
                                     3:530.41.03-1.fc38 @@commandline
                                     3:530.41.03-1.fc38 @@commandline
nvidia-gpu-firmware.noarch           20230515-150.fc38  @updates
nvidia-persistenced.x86_64           3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
nvidia-settings.x86_64               3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia.x86_64           3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda.x86_64      3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda-libs.i686   3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda-libs.x86_64 3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-kmodsrc.x86_64   3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-libs.i686        3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-libs.x86_64      3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-power.x86_64     3:530.41.03-1.fc38 @rpmfusion-nonfree-nvidia-driver

That all looks correct – except –
On my system I have 2 additional options in the kernel command line.

You can test those options by editing the command line curing boot.
When the grub boot menu displays (one may need to hold the shift key while booting to force it to display) press the e key to edit the options.
Then, on the line that begins with linux one may add one or both of these options to test the results.

I had to play a little to confirm that my system with an RTX 3050 gpu needed both of those options in the kernel command line for proper booting.

Once you have confirmed which (or both) of those options may work for you it is relatively simple to add them in permanently for future booting.

Thank you for the suggestions. I tried both on their own as well as together, and still the same issue. I recall doing something similar when trying to install Fedora 37. But with 38, I have had no problems untill some update.

I did notice a flash of my username on the greeter, but it disappears. I’m able to sign in as if it were there (press enter, then type in my password, then press enter). So it’s more strange than anything.

Maybe I should try to re-install gdm?

Before doing that it would be interesting to see the logs of what is happening.
Try booting with each config, then after logging in run dmesg > <filename> creating a new file for each.
Perusing the last part of those files may show what is happening differently during the boot.

The same outputs with journalctl -b > <filename> may also be of interest and allow one to identify what is different and where the issue occurs.

Your description seems to indicate that gdm may not be properly running plymouth which is the gui part of the greeter.

On F38 I see this

# dnf list installed plymouth*
Installed Packages
plymouth.x86_64                                                                               22.02.122-4.fc38                                                                @anaconda
plymouth-core-libs.x86_64                                                                     22.02.122-4.fc38                                                                @anaconda
plymouth-graphics-libs.x86_64                                                                 22.02.122-4.fc38                                                                @anaconda
plymouth-plugin-label.x86_64                                                                  22.02.122-4.fc38                                                                @anaconda
plymouth-plugin-two-step.x86_64                                                               22.02.122-4.fc38                                                                @anaconda
plymouth-scripts.x86_64                                                                       22.02.122-4.fc38                                                                @anaconda
plymouth-system-theme.x86_64                                                                  22.02.122-4.fc38                                                                @anaconda
plymouth-theme-spinner.x86_64                                                                 22.02.122-4.fc38                                                                @anaconda

Both gdm and plymouth rely on the nvidia driver running properly, so it also could be something wrong with the driver itself.
The driver can be removed and reinstalled with
sudo dnf remove '*nvidia*' --exclude nvidia-gpu-firmware
followed by
sudo dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda
then allowing at least 5 minutes for the drivers to be recompiled and installed before rebooting.

Well, it’s fixed. My mistake: I overlooked the need to put the two options on the line starting with linux, as you instructed. Sorry about that! Adding nvidia-drm.modeset=1 resolves the issue. To make this option permanent, I understand that I should add it to /etc/default/grub and then run sudo grub2-mkconfig -o /boot/grub2/grub.cfg.

In case you’re interested, I checked the system logs as well.

I ran dmesg twice: first without changes made to grub, and then with the option added. Looking at about the last 100 lines, from where “nvidia” is first mentioned to the end, the only difference (aside from some lines in a different order) is the very last character in the following line:

No changes:
[ 10.311628] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:08:00.0 on minor 1

With nvidia-drm.modeset=1:
[ 10.426212] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:08:00.0 on minor 0

Searching around, I found people reporting other nvidia-related problems and sharing “minor 1” and “minor 0” on this line. So it’s not clear to me that this is a pertinent difference.

journalctl -b
I went line-by-line through the two journalctl -b outputs, and found some differences. After the line inidializing nvidia-drm on minor0/1, I found the following, which I’ll first summarize. Without setting modeset, two GPU devices are mentioned: /dev/dri/card0 and /dev/dri/card1, whereas after setting the drm modeset=1, no such card1 is ever mentioned.

No changes:
Jun 10 12:11:23 fedora gnome-shell[2212]: Added device '/dev/dri/card1' (nvidia-drm) using atomic mode setting. Jun 10 12:11:23 fedora gnome-shell[2212]: MESA-LOADER: failed to open simpledrm: /usr/lib64/dri/ cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri) Jun 10 12:11:23 fedora gnome-shell[2212]: kmsro: driver missing Jun 10 12:11:23 fedora gnome-shell[2212]: Added device '/dev/dri/card0' (simpledrm) using atomic mode setting. Jun 10 12:11:23 fedora gnome-shell[2212]: Created gbm renderer for '/dev/dri/card1' Jun 10 12:11:23 fedora gnome-shell[2212]: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated Jun 10 12:11:23 fedora gnome-shell[2212]: Created gbm renderer for '/dev/dri/card0' Jun 10 12:11:23 fedora gnome-shell[2212]: Boot VGA GPU /dev/dri/card1 selected as primary

With modeset=1:
Jun 10 12:35:45 fedora gnome-shell[2187]: Added device '/dev/dri/card0' (nvidia-drm) using atomic mode setting. Jun 10 12:35:45 fedora gnome-shell[2187]: Created gbm renderer for '/dev/dri/card0' Jun 10 12:35:45 fedora gnome-shell[2187]: Boot VGA GPU /dev/dri/card0 selected as primary

gnome displays settings reset
A change I noticed upon setting the boot option: my displays in Gnome settings had changed. I noticed that the refresh rate was lower that before, so I checked it. I have one monitor hooked up. Before, “displays” registered two screens: my monitor as well as an “Unknown” 13.3" display. Now it registers only my monitor. Changing the refresh rate back to 144hz worked fine.

My plymouth packages are identical to yours.

Thank you very much, @computersavvy : )

Glad that my suggestions helped. Hope that you continue with the system working as you wish.