Solved it myself, find the guide for updating BIOS without a battery here:
Also, updated with this method from 3.07 to 3.10 (from Windows, because I have no knowlegde of the CLI switches needed to make it work via UEFI boot), no issues there. Was my first update and I panicked for a moment when the machine just shut off after the update. But turning it on revealed everything was working perfectly.
The â100% batteryâ requirement seems to be essential.
I had my battery set to cap charging at 80%, and the LVFS update did nothing. I changed the charge limit in my BIOS to 100% and fully charged the battery, and then the fwupdmgr update followed by a reboot installed the new BIOS correctly.
(By âcorrectlyâ I mean it installed 3.10; it still wiped out the BIOS settings so that I needed to reset all my BIOS customizations, boot with the âF3â boot menu, and re-install GRUB. But those are known problems with the BIOS update.)
Updated from 3.09 to 3.10 using
sudo fwupdmgr refresh
sudo fwupdmgr update
Opened the BIOS to reset my power button brightness and max battery level. Then rebooted and used F3 to browse to the image for y mcurrent Manjaro and re-install the boot manager. From the Manjaro Wiki:
sudo su -
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
grub-mkconfig -o /boot/grub/grub.cfg
exit
Rebooted and allâs well. Posting this here so I remember how to do it next time.
10mb remaining out of 100, so I suspect youâre on to something.
Is there a noob-friendly guide for resizing my EFI parition? There must be a way to do it that doesnât require command-line fluency, rsync, etc.
gparted will probably do it but the space has to come from somewhere, which means moving the beginning of the next partition. That will take a long time.
Iâll shorten the original question to avoid confusion about what Iâm looking for:
If youâre using systemd-boot, you could feasibly create an âExtended Boot Loader Partitionâ, which could be used to store things like the kernel without putting them on the undersized EFI partition.
https://wiki.archlinux.org/title/EFI_system_partition#Typical_mount_points
https://wiki.archlinux.org/title/Systemd-boot#Installation_using_XBOOTLDR
But, the other option is to try and resize the partitions after to then shift them down and then resize the EFI partition; most things Iâve read imply that they give up and just reinstall remembering to increase the size (or, if this is Windowsâ fault, trick its installer into using a larger partition than 100MB, its default).
Aw shucks. I was so happy with my config. Guess itâs time to learn some scripting for future installs so that this doesnât hurt so bad next time. If Iâm understanding things accurately, I hope the Fedora team sees this thread and adjusts their defaults.
Was this necessary? Iâm also using Manjaro and havenât had any of these updates wipe out GRUB.
It is necessary for a certain subset of users for whom their bootloader was not installed in the âfallback location.â
Technical details follow. Feel free to skip them.
UEFI systems will choose bootloaders based on a set of variables, BootOrder and Boot####. In the absence of those variables, it will look for a special file named BOOTx64.EFI in a certain folder.
The UEFI updates for the Framework Laptop (11th Gen) reset those variables. If your distribution installer places a copy of GRUB in the right place, it will automatically get picked up even when those variables are missing.
Updated by EFI Shell with no issues or problems (Ubuntu 22.04 lts)
Updated to 3.10 and everything so far seems to be working fine. As usual, had to reinstall grub as the EFI partition was overwritten.
Successful update from 3.09 to 3.10 using fwupdmgr on arch derivative.
If you are not seeing the newest firmware being reported by fwupdmgr, be sure to issue sudo fwupdmgr refresh, that is what made it show up for me.
Once again my boot variables that pointed the system to rEFInd went away (so it failed down to my backup installâs grub bootloader instead). I do appreciate the new feature to press F3 to navigate to my refind_x86.efi, as this and a simple ârefind-installâ puts everything back in order.
I can confirm the charging while shutdown behavior is fixed as expected, 40-55w charging under 3.10 vs 1w charging on 3.09.
Also, during the install of 3.09, the laptop went blazing hot. This did not occur during 3.10. I cannot remember if I changed the BIOS Performance toggle to max battery or not though, that might have made the difference.
Due to a bug report in another thread, I just double checked, and all 4 of my USB ports can take in power, pass data, etc.
Ran a quick suspend test as well and battery use was about 0.9% per hour, pretty similar to on other BIOSâs for me. I still would like to see the keyboard backlight go to zero by itself when the machine suspendsâŚ
Can confirm that a full reinstall was necessary to resolve my issue. The EFI System Partition size was indeed the culprit.
Glad to hear you got it sorted.
Ideally, the Windows / Linux firmware installation process should do a pre-requisite validation (EFI free space, in this case), and return meaningful error message if required.
Updated from 3.09 to 3.10 (and before that from 3.07 to 3.09) using the EFI shell method with no issues. 
(Running Fedora Kinoite 36)
Updated from 3.07 to 3.10 (smoothly through fwupdmgr) running Fedora 36 (stock) and none of my USB-C ports now work (including being unable to charge). Has this happened to anybody else? Anybody recommend a good place to start troubleshooting?
Thanks in advance
@warehows123 this is the first time I have seen a report like, this, I would suggest turning off your laptop, unplugging all power sources, waiting 2 minutes, and then plugging in your power adapter and seeing if it starts working.
@Damariscove you can usually clean up your grub partition and get more space by removing old Linux kernels.
I can confirm that Fedoraâs defaults are terribly stingy at provisioning for boot partitions: The defaults it chose when installing Fedora 35 on an old iMac were actually so low that the installation failed! When I retried with the only difference that I increased the size of the boot partition, the install succeeded without a problem.
I know that in my experience, the FW update used about 30MB. I donât recommend less than 500MB for the ESP if youâre multi-booting, since itâs possible that as kernels grow and more are added, it will create more undue complications for people. Windows typically creates one of about 300MB, and in a world of terabyte storage devices, 500MB is barely enough to think about.