I’ve been having the same issue! I’m surprised I didn’t see your post when I was writing mine. I just sent in a support request, since our issue seems to be easily reproducible.
Thanks a lot! I will check out, whether this fixes my issue.
Ahh, thanks for your input and linking your post. I’d love to hear what Framework says, when they get back to you. I will also try the fix linked by @Mario_Limonciello
@Mario_Limonciello, thanks so much for tracking down that bug report! As of February 2, it looks like the Noble Numbat main branch has a version of linux-firmware where the bug has been fixed: the changelog for version 20240202.git36777504-0ubuntu1 includes the “linux-firmware: update firmware for mediatek bluetooth chip (MT7921)” commit message. Is there a recommended way to install the Noble Numbat version of linux-firmware on a Jammy Jellyfish system? I’d prefer a method where:
- The package is installed and managed by APT.
- It’ll be easy to recover if my laptop can’t boot with the new firmware.
You can download the firmware binary manually from upstream and place it in the right structure in /lib/firmware/updates and then it should supercede the one packaged by apt. Whenever Ubuntu actually fixes the issue you can remove the one in /lib/firmware/updates.
Hey again, do you think you could maybe elaborate on how to do that and where exactly to find and download the files? I’m a noob and quite overwhelmed 
Would really appreciate it!
These are the 3 files you need:
mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
mediatek/WIFI_RAM_CODE_MT7961_1.bin
Build the directory:
sudo mkdir -p /lib/firmware/updates/mediatek
Browse here and then hit the download button
Move them over to that directory you made.
sudo mv *.bin /lib/firmware/updates/mediatek
sudo update-initramfs -u
Reboot and hopefully it’s effective if I got that all right.
1 Like
(@Max_Power, this is not normal. In my eighteen years of using Linux on laptops, I’ve never had to add firmware by hand like this.)
@Mario_Limonciello, I’m not used to adding firmware by hand. Could you check my understanding of how this fix works? Here’s the clearest picture I have so far.
- The command
update-initramfstells Ubuntu to load new firmware into the block of code that runs when I try to start my laptop.- This command is usually called automatically during a firmware update.
- I should be very cautious about calling this command by hand, because loading bad firmware can make it impossible for my laptop to start.
- When Ubuntu is told to load new firmware, it first checks whether there’s a directory called
/lib/firmware/updates. If there is, Ubuntu loads all the firmware it finds inside.- That directory doesn’t exist by default: I have to create it myself.
- Next, Ubuntu widens its search to the entire
/lib/firmwaredirectory.- All the default firmware that comes with Ubuntu lives here.
- In particular, the wi-fi firmware we’re talking about lives in the
/lib/firmware/mediateksubdirectory.
- If I have two different copies of a piece of firmware, Ubuntu will load the first one it finds, and ignore the others.
- For example, on my laptop, Ubuntu currently loads the default version of
WIFI_MT7961_patch_mcu_1_2_hdr.binthat lives in the/lib/firmware/mediatekdirectory. If I create the directory/lib/firmware/updates/mediatekand put a fancy version ofWIFI_MT7961_patch_mcu_1_2_hdr.bininside it, Ubuntu will load the fancy version and ignore the default version, because it will find my favorite version first.
- For example, on my laptop, Ubuntu currently loads the default version of
- If I stop liking the fancy version of
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin, and I want to go back to the default version, I just have to delete the version in/lib/firmware/updatesand tell Ubuntu to load new firmware again. Since the default version in/lib/firmwareis still there, Ubuntu will find it and load it. - If the fancy version of
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.binis so bad that it prevents my laptop from starting, I might be able to fix the problem by starting my laptop in recovery mode.- In recovery mode, my laptop avoids running most of the code that it usually runs when it starts. Hopefully, it will avoid the part that I screwed up.
- If my laptop manages to start in recovery mode, I can tell it to open a command line terminal. I can use the terminal to remove the bad firmware from
/lib/firmware/updatesand tell Ubuntu to load new firmware again.
Which parts of this are correct? Which parts are wrong? Is there anything important that I’m missing?
That sounds relatively accurate. The part I’m not sure about is if Ubuntu actually puts it into the initramfs or not by default. I am suspecting by default it doesn’t. So you can probably omit that step.
If it doesn’t put it in the initramfs and you run into a problem, delete the file, reboot and you’re back to the one provided by Ubuntu.
Let me repeat what you wrote to make sure I understand.
- It could be that Ubuntu loads new firmware into the initial RAM disk automatically, without having to be told. In that case…
- I don’t have to call
update-initramfsmyself. - If the new firmware makes it impossible for my laptop to start, I can fix the problem just by removing the new firmware file from
/lib/firmware/updatesand restarting. - That means I might be able to fix the problem even if my laptop can’t start in recovery mode. I can start my laptop using the same bootable USB drive I originally used to install Ubuntu, this time choosing the Try Ubuntu option instad of the Install Ubuntu one. I can use the trial version of Ubuntu to remove the new firmware file and restart my laptop.
- I don’t have to call
Accurate?
No; I mean that I don’t know for sure they even package it into the initrd. I seem to recall the driver loads after the initrd. You’d have to double check the boot sequence to know for sure.
Unlikely it would cause that problem; but yeah if it does that’s how you would fix it.
I would just boot into recovery mode and delete the file.
Thanks for clarifying! I can’t figure out how to look up the boot sequence, so I’ll just try dropping in the new firmware without updating the initial RAM disk. Then I’ll reboot and call modinfo mt7921e to see whether the new firmware is running. (Can I actually tell the difference between the new and default firmware that way?)
You should compare lines from dmesg to tell whether it loaded.
2 Likes
Dude, thanks so much for taking the time for such a detailed walkthrough. My Wi-Fi is not dropping anymore!
Really appreciate your help 
2 Likes
Mario_Limonciello I spoke to soon, my Wi-Fi is randomly dropping again.
And since my Framework now also started randomly shutting when I close the lid, instead of staying in sleep, and since I also regularly get the pop-up that gjs.console crashed, I am unfortunately done with the Framework.
So many bugs and issues in such a short time just make it unusable for me as daily driver. I don’t know if the problem is the Framework or Ubuntu or both, but I need a Laptop that just works.
So, unfortunately I have to go back to Apple and buy a MacBook, even though I really don’t want to.
Man, I can’t even put my disappointment into words.
1 Like
Update: whoops, I didn’t notice the other bugs you mentioned. Yeah, I can understand why you’d just give up at this point.
@Max_Power, the new firmware may not actually be running. You should be able to check by calling the command
sudo dmesg | grep mt7921e
soon after you start your laptop. The sudo dmesg part prints out the kernel’s message buffer, and the grep part searches for messages related to the wireless driver.
When I did this before trying to install the new firmware, I got this output:
[ 2.302579] mt7921e 0000:01:00.0: enabling device (0000 -> 0002)
[ 2.311065] mt7921e 0000:01:00.0: ASIC revision: 79220010
[ 2.399380] mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20221227123154a
[ 2.778037] mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20221227123243
[ 3.867760] mt7921e 0000:01:00.0 wlp1s0: renamed from wlan0
When I did it after installing and rebooting, both of the “build time” numbers were the same, suggesting to me that I’m still running the old, broken firmware.
@Mario_Limonciello, am I correctly checking whether the new firmware is running? If so, why isn’t it running?
1 Like
If none of those strings changed I would say it’s likely not getting loaded. Check the file structure you put the new files in matches properly.
1 Like
My wi-fi just dropped again too, which is consistent with my perception that the new firmware isn’t running. @Loell_Framework, I know Mario is the expert on Linux on AMD, but I don’t want to keep leaning on him for support that Framework should be responsible for.
1 Like
The commands below ran without error in /lib/firmware, which shows that the new binaries are at the paths shown.
diff mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin updates/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
diff mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin updates/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
diff mediatek/WIFI_RAM_CODE_MT7961_1.bin updates/mediatek/WIFI_RAM_CODE_MT7961_1.bin
The output confirms that the new binaries are different from the old ones.