As Mario has indicated, this is a known Ubuntu bug that is in process to be sorted out.
It’s also worth noting this does not affect all router connections, as it does not affect my own for example - this makes duplication very tricky. That said, it is a known bug and it is coming out as a fix in future updates.
If after following the suggestions provided by Mario, you’re still having issues, you may open a ticket where we can provide additional detailed steps to work through after reviewing your logs at length. When doing so, please link this thread into the ticket to provide additional context.
Linux will present bugs from time to time, so we work through them as we can as fast as we can.
Unofficially: Some folks who have found the MediaTek card isn’t something they wish to work through have opted for the Intel AX210 wifi card as a fallback while these issues are worked through.
If after following the suggestions provided by Mario, you’re still having issues […]
As we’ve been discussing, Mario’s proposed fix doesn’t work as written, possibly because of this change in Debian’s firmware search path. I’d very much appreciate either a way to modify the search path or, as a last resort, someone at Framework testing lbkNhubert’s riskier suggestion before I try it on the machine I’m currently using.
I opened a ticket on Monday. (I wasn’t given a ticket number, but the submission time was around 05:30 GMT.) The initial support request linked to both this community thread and the parallel one that I opened. So far, I haven’t seen any substantive support from anyone labeled as a Framework support team member, either on the community forum or by e-mail.
As Mario has indicated, this is a known Ubuntu bug that is in process to be sorted out.
Since this is a known bug, and the Laptop 13 (AMD Ryzen 7040 Series) ships with a MediaTek wireless card, I’m confused about why the compatibility guide says that wi-fi and bluetooth work out of the box under Ubuntu 22.04 on this machine.
After this issue is resolved, I’d appreciate a better understanding of the testing routine that Framework’s compatibility guides are based on. This will help me calibrate my expectations for the guides’ accuracy.
Getting things setup on my end now for replication and eyes on it.
However, at the time of the guide, yes, it worked out of the box. This may shift if the patch is held up too long. But I just connected to my wifi router just now without any issue.
The issue affect some routers, not all (and not that I have access to). So right now, I am focused on path differences and getting the correct firmware sorted. I will then examine the state of the patch release, determine if we need to adjust the works out of the box state of wifi from there.
Works with workarounds generally means when I go to connect, it does not. This has not been the case. The issue is the dropping - which has not happened in our testing, and recently, has shown itself to the surface. So we’re going to laser focus on resolution for that.
Getting things setup on my end now for replication and eyes on it. […] The issue affect some routers, not all (and not that I have access to).
If there’s anything I can do to help you replicate, please let me know. I’m using networks on these two routers:
TP-Link Archer C4000 (both 2.4 GHz and 5 GHz networks)
Ubee UBC 1322 (router chooses between 2.4 GHz and 5 GHz for each connection)
I haven’t been able to maintain a stable connection on either of them.
The issue is the dropping - which has not happened in our testing
Most reports of this and similar issues describe drops happening “after a few minutes” (this thread) or “about every 20 minutes,” which is consistent with my experience. The laptop has sometimes maintained a connection for as long as a few hours, but I don’t think it’s ever gone more than eight hours without dropping.
Appreciate it. I am digging into Ubuntu 22.04.3 using the /lib/firmware/mediatek directory path found for this release. This is path for Ubuntu and we have another individual who has had success here. So working this out now.
You did indicate something about path as /lib/firmware/updates for Debian - I cannot speak to this as with our tiny team, we have not touched anything with that distro. If I followed this correctly, seems you indicated Debian in this instance?
In any case, I will have something for Ubuntu shortly to be crafted as a one an done, although it may be a temp stop gap until the Noble fix rolls into LTS.
Tested this manual approach, rebooted without any issues. I will need to aquire a 6E compatible router to make sure all remains well as my older config may be misleading.
Please wait for the beta of the one liner coming shortly, this is for detailed informational purposes only.
cd Downloads && sudo mv *bin /lib/firmware/mediatek
Reboot
Seems to be good. But I lack the 6E+ wifi. But on my wifi 6 router, smooth as butter.
Since I have static bin files I can pull down, I’m going to toss together something for folks to beta test for me until I get a newer router setup here. It will be a one liner script:
Once I get it tested here.
Copy, paste, run, reboot.
This will buy us time while we wait for the Ubuntu team.
You did indicate something about path as /lib/firmware/updates for Debian
Like Max_Power, I’m running Ubuntu 22.04. I wanted to understand why update-initramfs wasn’t loading the new firmware from /lib/firmware/updates, even though that directory is on the generic Linux kernel firmware search path. I suspect the answer is that Ubuntu, being a Debian-based distribution, uses the Debian firmware search path, which apparently—as of Debian 8—only includes /lib/firmware.
Thanks for testing! For the benefit of any new users who might follow these instructions in the future, I want to quickly flag a problematic one:
# [don't do this] cd Downloads && sudo mv *bin /lib/firmware/mediatek
This can have unpredictable effects, which depend on the contents of the Downloads directory. I’d recommend editing your post to specify only the names of the binaries we want to move.
Can you confirm that just replacing the binaries in /lib/firmware/mediatek and rebooting—without calling update-initramfs—was enough to get the new firmware running? I just did this, and I’m still seeing the same build times 20221227123243 (for “WM Firmware”) and 20221227123154a (for “HW/SW”) in my dmesg output, suggesting that the new firmware still isn’t running. What does your dmesg output look like?
Checking now - Okay, I am seeing the same.
driver: mt7921e
version: 6.5.0-1014-oem
firmware-version: ____000000-20221227123243
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
I will have to circle back to this on Monday when I return to the office.
(Note: I’m on Noble (24.04) on this system for looking at other newer kernel bugs, so it came directly from the linux-firmware package for me)
I’m not sure why the /lib/firmware/updates search path isn’t working for others though. But at least when it’s working you can reference the above versions.
Thanks for confirming the build times for the new firmware!
I’m not sure why the /lib/firmware/updates search path isn’t working for others though.
I’m pretty sure it’s not working for anyone, because that directory hasn’t been on the Debian search path in over a decade. I can’t find any documentation about the Ubuntu firmware search path, so I’m guessing it’s taken from Debian.
I’ve now tried replacing the binaries in /lib/firmware/mediatek, calling sudo update-initramfs -u, and then rebooting. I still see the old build times in my dmesg output, and I’m still having wi-fi symptoms consistent with what I saw when I first set up the laptop, so I don’t think the new firmware is runnning.
@Matt_Hartley thanks for weighing in! I’m at work now and will be able to respond later today and I’ll also try running sudo dmesg | grep mt7921e to check, whether the manual FW update has been loaded.
So, I ran sudo dmesg | grep mt7921e and I had the same build times as @Aaron_Fenyes , which is why I believe, that the firmware update hasn’t loaded. Makes sense, since I have constant Wi-Fi drops at home.
Since @Mario_Limonciello is the only one, that got the updated firmware to load and is also on Noble, I’m assuming the latter is the reason for it to work for him.
I’m not sure, what to do now. Maybe I’ll switch to Windows or Fedora, until the bug has been fixed.
Or would it make sense to upgrade to Ubuntu Noble? I’m asking because for privacy reasons I’d rather not use Windows and I use the Signal messenger a lot, which is only officially supported for Ubuntu/Debian and macOS/Windows.
The updated firmware is already part of Noble—I think that’s why Mario has it.
If you’re interested in trying a new distribution, you might consider Debian, which Ubuntu is based on. I have the impression that a lot of bug-fixes that affect Ubuntu are available sooner in Debian. We could ask Mario how stable Noble is right now. It’s under development, so it’s likely to have some hiccups—but the bugs affecting your hardware seem worse. (By the way, are you still getting the shutdowns on lid close and the gjs.console crash pop-ups? Did those start before or after you tried to add the new firmware files to /lib/firmware/updates?)
As a possible temporary fix, I’m going to try booting into a 6.2 kernel, because one comment in the bug report mentioned the problem only showing up after upgrading from 6.2 to 6.5. The package manager tends to keep old kernel images around—I think for situations like this. You can see which kernel images you have available by calling dpkg --list | grep linux-image. I’ll report back on how it goes.
Okay, booting into a 6.2 kernel doesn’t seem feasible, because I can’t get a GRUB menu—only the GRUB command line. My attempts to boot from the command line have failed, and the procedure is finicky enough that I wouldn’t recommend it even if it worked for me.
Loading new firmware binaries still looks like the most promising strategy, unfortunately. I’ve asked for help with this on Ask Ubuntu, because it doesn’t seem hardware-specific.
