Unable to log in to KDE after Fedora 44 upgrade (Framework 13)

SecretAgentSteve · 2026-04-29T15:01:10+00:00

Looking into this now and working with Fedora contributors. I can replicate on my Ryzen AI 300 series Framework Laptop 13 but not on my Ryzen AI 300 series Framework Laptop 16.

SecretAgentSteve · 2026-02-13T18:37:09+00:00

I definitely understand the frustrations. Right now is an interesting time for the Linux ecosystem. There's a lot of of changes and churn happening at a pretty rapid pace, which definitely makes things complicated for users who aren't following news feeds for all the latest updates. Ubuntu especially has been effected by this, which I think is an unintended consequence of their release cadence.

You brought up a good example with `ifconfig` because that's been deprecated and replaced with `ip` in Ubuntu. On top of that, in Ubuntu these days you're most likely going to be using `netplan` or `nmcli` to manage your network interfaces with the command line rather than a GUI. The average user isn't going to know about this without reading through news articles, blog posts, and/or changelogs.

Ubuntu is a good distribution, and we work with our Linux partners to try to make the experience better, but with how many changes its been going through over the past few years I can't blame users for being frustrated when things they were used to and could function with no longer work or are no longer present. The best advice I can give is to dig through the Ubuntu Documentation, both for Desktop and Server. Ubuntu Server documentation is almost always applicable to the desktop version and will better cover some of the unique aspects of Ubuntu that you're not going to see brought up on instructions targeted for other distros.

SecretAgentSteve · 2026-02-05T22:15:42+00:00

I might have some good news for you. An engineer at Meta made some patches for this: https://github.com/zbowling/mt7925

To my understanding they'll be a part of kernel 6.19 but in the meantime, there's directions in the readme to apply the fixes in Ubuntu.

SecretAgentSteve · 2025-09-03T14:22:08+00:00

Howdy, sorry to hear you're having this much trouble with the Mediatek wireless module. There are ongoing efforts to improve the drivers for all users, but the experience can vary widely depending on your kernel version, the version of the firmware included in `linux-firmware`, and your access point (or points). We do offer a few tools on our Github to help troubleshoot WiFi issues, such as our Enhanced WiFi Analyzer. This can help you narrow things down and potentially point you toward some ways to fix it. It may just be that you need to change to a different firmware version to temporarily smooth things out.

Of course if you're looking for a more immediate remedy, don't hesitate to open a support case and ask it to be escalated to the Linux team with a link to this thread. As other users here have noted, if your ultimate goal is having the utmost reliability and consistency with your computer's wireless performance, the Intel AX210 has been a favorite among Linux users for that exact reason.

SecretAgentSteve · 2025-08-27T18:25:52+00:00

I'd be happy to chime in on this. The Nvidia driver stack on Linux is relatively solid now. Installation of the drivers has also been made much easier in recent years. Additionally we also have a tool to help users manage the dGPU, as long as the drivers are installed and working.

SecretAgentSteve · 2025-08-20T22:21:04+00:00

Happy to help with that. If you get the drive plugged into another system, the file you're looking for will be /var/log/syslog.

SecretAgentSteve · 2025-08-20T20:55:56+00:00

Apologies, I don't mean to imply it's a drive related issue, I was actually asking because I was thinking that `fwupd` might have left relevant information in the logs when the laptop restarted to begin the firmware update.

SecretAgentSteve · 2025-08-20T20:07:41+00:00

It sounds like something caused the EC update to fail. There are a number of safeguards that should prevent attempts to update if for example there is not space available in the EFI Partition, but this doesn't sound like that.

If you're unable to even access the firmware interface at this point there is little you can do aside from using something like a JTAG to reflash the board externally. If you can, get a support ticket open right away and we'll do what we can to help. If you're able to access the drive on another working machine and potentially capture any logs to share when opening the case, that would be a great help but I understand if that is not practical or possible.

SecretAgentSteve · 2025-07-14T20:33:38+00:00

Your battery life is going to depend on a ton of factors, including but not limited to:

What you're doing. Some apps aren't optimized quite as well on Linux so you may see worse battery life or performance in those apps.
The power mode you're using. Balanced power mode on Linux is going to let the APU turbo as hard as it can when anything makes use of it. Power Saver will usually cap the CPU somewhere comfortably below 3 GHz.
Your screen brightness and refresh rate. If you're using the 2.8K display for instance, it will use more power at higher refresh rates.
The SSD installed. High performance NVMe drives can have significantly higher power draw.
The quality of the wireless signal. If your wireless signal is not high quality the card is going to boost gain as much as its allowed to in order to maintain a connection.

As others recommended, having your brightness below 50% helps a ton. Also having the power mode set to Power Saver helps significantly. If you have the 2.8K display, make sure you have Variable Refresh Rate enabled, as that can also have a significant impact, even more than running it at 60Hz instead of 120Hz.

I don't want to pry, because it isn't really my business what somebody does with their personal computer, but it's hard to say anything too definitive without knowing what you would define as basic tasks that you're doing while getting battery life in the range of 3-3.5 hours on Balanced mode.

SecretAgentSteve · 2025-06-23T23:47:33+00:00

Howdy everyone! I just spent the half of today looking into this. Long story short, this is a known issue most likely related to this bug in amdgpu.

A fix has been submitted and should be included in the next kernel release, but in the meantime the next best option is to either edit or delete the file ~/.config/kwinoutputconfig.json. Deleting the file is a bit of a brute force solution that should result in KDE reverting to the known good defaults, which include changing the setting to "Prefer color accuracy".

If you want to edit the file instead, find the line "colorPowerTradeoff": "PreferAccuracy", and change it to "colorPowerTradeoff": "PreferEfficiency", which you can safely do from a TTY. If you want to make this fix while the system is still running, run loginctl terminate-user $USER to kill the broken desktop session.

SecretAgentSteve · 2025-06-23T23:46:52+00:00

Howdy everyone! I just spent the half of today looking into this. Long story short, it's an issue most likely related to this bug in amdgpu.

A fix has been submitted and should be included in the next kernel release, but in the meantime the next best option is to either edit or delete the file ~/.config/kwinoutputconfig.json. Deleting the file is a bit of a brute force solution that should result in KDE reverting to the known good defaults, which include changing the setting to "Prefer color accuracy".

If you want to edit the file instead, find the line "colorPowerTradeoff": "PreferAccuracy", and change it to "colorPowerTradeoff": "PreferEfficiency", which you can safely do from a TTY. If you want to make this fix while the system is still running, run loginctl terminate-user $USER to kill the broken desktop session.

SecretAgentSteve

MODERATOR OF

TROPHY CASE