Kinoite 44 Upgrade Hangs Post-Login (Black Screen/Mouse Freeze) on Framework AMD Ryzen AI 5 340

Ask Fedora
, , , , , ,
1

I am attempting to upgrade from Fedora Kinoite 43 to Fedora 44 on a Framework Laptop (AMD Ryzen AI 5 340 w/ Radeon 840M).

The rebase and deployment finish without any issues. I can boot into the Fedora 44 deployment and reach the SDDM login screen normally. However, immediately after entering my credentials and logging in:

  1. The screen goes black, but the mouse cursor remains visible and moveable for about 15–45 seconds.
  2. No audio (KDE start sound) plays.
  3. The mouse cursor eventually freezes, and the system drops to a TTY/text screen displaying filesystem and service crashes.

Isolated Variables & Diagnostics Logged:

  • Firmware is up-to-date - Running 5-Feb-2026 — v3.05

To rule out local configuration issues, I ran sudo rpm-ostree reset to clear all layered packages and overrides before performing the rebase, but the issue persists on a completely vanilla Fedora 44 base image.

I rolled back to my pinned Fedora 43 deployment to pull the logs from the failed boot (journalctl -b -1 -p 3). The crash appears to be a domino effect triggered by a storage layer write failure immediately upon entering the graphical desktop session:

PlaintextBTRFS error (device dm-0 state ER): run_delalloc_nocow failed, root=257 inode=325 start=0 len=4096 cur_offset=0 len=4096: -5 coredump: 2283(kded6): /usr/lib/systemd/systemd-coredump pipe failed coredump: 2414(org_kde_powerde): /usr/lib/systemd/systemd-coredump pipe failed

Hardware/Filesystem Verification:

Because the kernel threw an I/O error (-5), I thoroughly checked the health of the underlying LUKS encrypted volume and SSD from Fedora 43 to rule out hardware failure:

  • sudo btrfs device stats /sysroot returns 0 across the board for all read/write/corruption counters.
  • sudo btrfs scrub start /dev/dm-0 completed successfully with no errors found (95+ GiB scanned).

Given that the drive structure and hardware are 100% healthy under Fedora 43, this looks like a runtime kernel or BTRFS driver regression specific to this newer AMD storage controller/LUKS mapper stack in Fedora 44.

Has anyone else encountered this post-login allocation failure on similar Framework hardware, or is there a known workaround for this specific block device mapper conflict?

2

Make sure to update all firmwares on Framework laptops as that’s a common way to fix issues.

3
  • Firmware is up-to-date - Running 5-Feb-2026 — v3.05
4

I have100% given up on trying to make this work. I did everything I could think of, and, at the end of the day, nothing worked. I didn’t want to go with Silverblue, so, I migrated to Sway Atomic, and once I got past the learning curve of SwayWM, I actually like it better than KDE Plasma. So, this is my solution to this problem. :+1: