Add: same issue when attempting to boot into a F44 live ISO; the USB drive keeps being accessed, but KDE doesn’t show up (only the mouse cursor appears). The only difference is that Ctrl+Alt+F2 works.
If you can sign in on the console, can you grab some logs from, e.g., journalctl -b -1? If the network also works, maybe pipe some logs to fpaste and share the link here?
Thanks for the reply! I only seem to be able to sign in on the console before I try to login and shortly after (sometimes, after attempting to log in, it just throws me back to login screen). After login starts (KDE splash logo), I am either no longer able to go back to the console (and the laptop needs to be turned off manually), or journalctl has stopped.
I am getting similar behaviour when booted into a Live ISO, but not when I boot the same installation from USB with in a VM.
Yeah, seeing that the same image works in your VM, it is almost certainly something about your hardware. I’m very surprised that a Framework laptop would have a problem like that though.
If it worked before you upgraded, do you still have the Fedora Linux 43 kernel installed on your system? You should try holding Shift while booting the system to get the boot menu to show and then select the Fedora Linux 43 kernel and see if it works with that. Most of the hardware drivers are in (or packaged with) the Linux kernel.
P.S. That sudo journalctl -b -1 command will show the logs from the previous boot, so if you reproduce the problem, reboot (preferably a “soft” reboot by switching to one of those VTs and holding Ctrl+Alt+Del), and then sign in and run that command on the console, it should show you the logs from the previous boot when the error occurs (what you are interested in will probably be somewhere near the end of the logs).
It worked with the F43 version of the same kernel (6.19.14). I tried with 6.19.13 now, got a crash, too (this time it’s a BTRFS: error (device dm-0) state A) in btrfs_run_delayed_refs:2165: errno=5 IO failure).
Browsing through the log from previous boot there’s a line with a coredump Process 3376 (kcminit_startup) of user 1000 dumped core with a very long list of modules, followed by core dumps caused by kde6, ksmserver, ksecretd, plasmashell, drkonqi-coredum and a several others (some of them more than once), all in the space of a few seconds/minutes.
Ah, yes, if the filesystem is corrupted, then that could explain it. Not sure why it would work in a VM though. Maybe some specific kernel module is corrupted that isn’t needed when the OS is loaded in the VM?
Repairing a Btrfs filesystem isn’t something I’m skilled at though. You might edit the title of your initial post and add the Btrfs tag. That might summon someone who would know how to repair (or at least verify) a Btrfs filesystem.
Edit: Hmm, wait, “IO failure” probably indicates a problem with the connection or port that your expansion card is in, not necessarily the filesystem itself. But then why does it work with the previous kernel? Maybe the connection is too slow and the timeouts have changed in the newer kernel? I don’t know. This seems like a hard one.
Yes, I thought that maybe something is wrong with the expansion card, but it works perfectly well in a VM when the card is in the same slot on the same computer (just booted into Windows) and it also doesn’t explain why live KDE ISO doesn’t work. I will try a Gnome F44 ISO as well.
Seeing that it works with the older kernel, you might have found a problem with the newer kernel. A bad device driver could generate an IO failure. I’d avoid removing that Fedora Linux 43 kernel that you know works and see if you can figure out what kernel version it stopped working at.
Is there a correlation with the ISOs that do or do not work? What does uname -r show when running a working ISO? Ah, but that would be meaningless because the ISO wouldn’t be accessing the card in the expansion slot.
I’m not sure I’m parsing that correctly. When you select a kernel in the boot menu, I think it will be labeled with either (forty three) or (forty four) at the end of the name? The “forty three” kernel boots your system, but the “forty four” one(s) do(es) not?
Maybe the IO failure is a false lead. Maybe that is only showing up after the crash? If so, maybe something else is actually causing the crash, like a bad video driver maybe?
Booting into F44 Workstation (Gnome) Live ISO works fine. So the way things look like to me, something looks off with some of KDE packages that got updated in F44.
That report concludes that the problem was caused by an incomplete system update. Can you run sudo dnf distro-sync from your console to try to make sure all the packages are updated?
I’ve re-flashed the KDE F44 Live ISO to the thumb drive that worked fine with the Workstation (Gnome) F44 version and got a crash in live environment again (autologin → splash screen → mouse cursor forever, with a flashing USB drive). Again seeing some read errors and core dumps in journalctl -f but the USB drive was verified after flashing and at boot.
I guess I will be waiting for updates and hope for the best. The fact that live ISO doesn’t work suggests it’s not an issue with the upgrade.
Well, someone will have to report the problem to a developer before a fix will show up, but yes, that might be what you have to do in this situation.
If you can grab that crash dump somehow and report it on bugz.fedoraproject.org, that might get the attention of someone who can actually fix the problem.
Sorry that I wasn’t very helpful. I’m at the end of a long day.
I dont know if these can help but i had the same issue with fedora workstation when i updated to f44 it kept looping to the type your password page i fixed it by renaming the gnome config to .backup
These were what i did
mv ~/.config ~/.config.backup
mv ~/.local ~/.local.backup
reboot
After that it worked but i ofc lost the wallpaper and the the extentions but not my data atleast and apps and everything is still there