Hello bro I am having the same issue on mi notebook 14 laptop even on fresh install and I have noticed one thing after updating software in app store it shows two fedora entries in grub I am a new to Linux so I don’t know much anyways did you get any fix for this issue?
I used to have the same problem and I couldn’t exactly point out what was causing that.
I can’t say for sure what changed, but my screen no longer gets stuck on the login screen after entering the password since upgrading to Fedora 40 from 39.
Last time I tried, similar behavior was reproduced on F40. Had to go through startx.
Grub should probably show multiple entries with different kernels after such updates. Sometimes kernel updates can break graphics which causes login screen probs as well.
I’ve had this happen since I think late F38 or F39, and it happens on F40. I had it happen about a week ago with openSUSE TW also (I didn’t run into it prior to that and thought this was Fedora-specific).
Intel UHD 630, Xorg or Wayland. I suspected it had to do with audio because sometimes I’d hear my speakers pop on that screen, but disabling onboard audio nor using several USB audio cards fixed it.
When that gray-screen pause happens, on Xorg sessions I can unplug my 3.5mm speakers, plug it back in (to trigger a what device headphones/headset/mic prompt), Win key + L to lock, and recover out of it, but that assumes I have something in 3.5mm (no recovery with just my laptop by itself).
Anyone have any ideas on where to even begin to diagnose this? This basically makes Linux (in most distros providing GNOME primarily, including Fedora), unstable and unusable. It’s a joke to be gambling on logging in.
This appears to be commonly-reported on Arch and Manjaro too 2023-2024. Some hints are at NVIDIA and SimpleDRM or something, but I’ve seen AMD reports, and also have it on my Intel UHD 630 single-GPU.
Just added a few tags but these are very likely different issues.
Please instead of using startx use the actual terminal command to enter the session from the gdm login manager and post the individual outputs.
I dont know what command that is, it might be using loginctl.
The original post was more than 6 months ago and probably with f38 or earlier.
Discussion on a similar problem should be done in a new thread since the relevant OSes are all EOL at this point.
.
I will split this topic and all posts following yours.
1 Like
That’s when it started happening for me (late F38 or possibly F39), and still happened May 2024 GNOME 46 on F40 and openSUSE TW.
Ok
But we need to work on things as they are NOW and not as they may have been 6 months ago. A current thread with current information is the best choice, even if you link the older thread as similar for added information.
1 Like
I haven’t seen this happen in about a day so far on F40 after disabling Wayland in /etc/gdm/custom.conf and making Xorg run as root:
echo 'needs_root_rights = yes' | sudo tee --append '/etc/X11/Xwrapper.config' > '/dev/null' && cat '/etc/X11/Xwrapper.config'
Edit: Nope, saw it happen a little bit ago. I was messing with 2 different USB-C docks and USB audio. I saw in journalctl mentions about gsk not finding the default audio sink, so this has me thinking again that it’s audio-related somehow. Wiping out wireplumber in local/state didn’t help.
Saw MUTTER_DEBUG_KMS_THREAD_TYPE=user suggested somewhere and I’m testing that now.
Prior to setting that, I had this happen earlier today F40 latest updates nothing special. I was hoping it’d be magically fixed after 2 weeks of gamble-free log-ins with Windows 10 
No-go with MUTTER_DEBUG_KMS_THREAD_TYPE=user.
I noticed it didn’t happen at all up for a few days until I changed some BIOS settings related to CPU power management (HT, SpeedShift, C-States, etc), then I had it happen inconsistently but frequently.
I thought a complete BIOS reset (Dell reflash with rcv, bios settings restore from usb, and nvram clear) would undo any trace of anything problematic but I still had it happen immediately on the next boot.
I wiped old monitor and wireplumber confs from my user and gdm, enabled some extra BIOS stuff (VT, TPM), and trying Wayland now; I don’t expect this to really change anything, but if it happens again I think I’ll try the GNOME Classic session Happened on Classic (Wayland) too.
I’m going back to W10 stability for a bit and then if I get bored likely to Fedora Xfce, or maybe another try at Plasma 6. I might revisit this again if I find any other wild ideas to try.
Does anyone have any kind of actual troubleshooting for this yet? As-tempting as it is to just use Windows 10 and WSL or VM and have worry-free logins, I still like messing around on GNOME on Linux
Do you get an abort report like the one shown in the earlier screenshot? If so, and if you don’t mind, can you report the crash to Fedora’s problem reporting system and share the link here?
FWIW, just skimming the reports of “gnome-shell” crashes that are currently in the system, it looks like several that are coming in of recent for Fedora Linux 40 (170 reports as of this post) are happening in /usr/lib64/dri/radeonsi_dri.so (ABRT Analytics - Report #951815 - gnome-shell in __pthread_kill_implementation). If the lower-quality video is acceptable, you might try using the generic VESA driver as a workaround until the problem is resolved (and let people know with a post here if that successfully works around the problem).
1 Like
No reports or anything under Problem Reporting. I’m not sure if anything is crashing, but it seems like it just hangs and waits for something.
The X cursor changes to a regular pointer if I unplug my 3.5mm and plug it back in on Xorg, and from there I can Super + L to lock and unlock. Without doing the 3.5mm hotplug, the cursor stays a X and Super + L doesn’t do anything.
Maybe your system (or at least your video card) is stuck in some odd power management state and the 3.5mm hotplug is waking it out of that state? Is your system using the radeon or amdgpu driver?[1] If so, setting aspm=0[2] and/or dpm=0 might worth a try if you don’t mind the extra power drain while your system is turned on. Use something like cat /sys/module/amdgpu/parameters/aspm to verify that the desired setting is in effect once your system is booted.
$ modinfo -p amdgpu | grep aspm
aspm:ASPM support (1 = enable, 0 = disable, -1 = auto) (int)
Edit: Or perhaps as a more thorough way of testing to see if power management is to blame, you could just add pcie_aspm=off to your kernel command line to completely disable ASPM.
No, it’s Intel UHD 630
I also have pcie_aspm=off already
1 Like
It still sounds like it might be some sort of power management bug. There have been several reports of problems with the newish s2idle power saving state in recent months : Search results for 's2idle' - Fedora Discussion. You might trying disabling that. Otherwise, without some sort of corresponding log message to hint at what the problem is, it could be very difficult to find the cause of this issue.
This seems to have worked for me. Before this I was having to switch over to tty2 > login and startx. If there is any more info I can provide that might help fix this issue, let me know
@Espionage724 I have read all the posts in this thread and to me, it’s a strange problem. I have a PC consists of an AMD processor, a Nvidia graphics card, two SSDs - one for Win 10 and another for Fedora 40 - no dual boot and with other accessories and I faced no such problem… yet. Yes, I have an audio system plugged in the 3.5mm jack in the back panel of the motherboard and a headphone plugged in the front panel 3.5mm jack. Although I am not using GNOME DE, instead I am using KDE Plasma 6 DE and disabled GDM and using SDDM as required by KDE. But I think, this problem is not a fault of the system but it is a signal problem because of faulty hardware, probably in the speaker system. Something causing an electrical short circuit which is sending a wrong signal to the system and it halts. In my lifetime, I have seen such things in Windows too but there, either Windows hanged or crashed with its infamous BSoD. Even sometimes it crashed so badly that I had to reinstall the OS again without anything plugged in the 3.5mm jack and it worked normally. I will suggest to reinstall the current release i.e Fedora 40 without plugging the audio jack in the computer’s 3.5mm jack. Then see what happens. But it is probable that you might already experimented with it and I might be wrong and if that so, please forgive me for trying to make a reasonable answer.