Didn’t work for me the first go either. I had to follow the above instructions, and add -allowsv option. Got a green progress bar on the update this time.
- Extract contents of zip folder to a fat32 formatted usb drive.
Just a bit vague. Exact commands would cause fewer issues, IMO.
I seem to be facing a similar issue - I’m on Aurora. After upgrading to BIOS 3.19 this morning, it worked fine through the day. Then, this afternoon, it got stuck in a boot loop.
In addition to the power button behavior you’re describing, it LED on the side is solid green for a bit, then blinks green with some occasional orange and blue.
In the meantime I could fix the issue by disconnecting the internal battery (and the cmos battery, but I’m not sure, if that had any impact), wait a few minutes and booting the notebook afterwards.
Experiencing the same issues upgrading from BIOS version 3.10 to the latest BIOS version. I’m currently running Linux Mint 21.1 on 11th gen Intel, and I’ve tried the following with formatting the drive:
mkfs.vfat -F 32 /dev/sda, and then re-extracting the contents of the provided zip over to the thumbdrive.Subsequent attempts were executed with the prompt fwupdlcl.efi -F fwupdate.bin -y -allowsv as mentioned above. The last two attempts, I made sure that my battery did not go above 90% to ensure that the machine was in a charging state when attempting another BIOS update and I also reboot the machine after logging into my Desktop after each attempt, to try and force the FW to load on the next reboot to no avail currently. I’ve checked both with sudo dmidecode --type bios as well as booting into setup, and both report the version to be at 3.10.
It’s a relief to know there’s a fix, thank you! Is the fix persistent or did you downgrade your firmware once you got your laptop booting again?
Took me two tries as well, first go-round left 3.17 installed.
I also used the -allowsv parameter, though I didn’t wait for a second failure before adding it.
And the next day booting, we’re back to the old behavior of bootlooping 
I was able to boot again. I have no real idea under what conditions it boots correctly anymore. *sigh*
But at least I found out, that I’m suffering the same issue that dmidecode reports the former Bios version:
Vendor: INSYDE Corp.
Version: 03.07
Release Date: 12/14/2021
Address: 0xE0000
If you’re seeing the same behavior I was, if you change the line
fwupdlcl.efi -F fwupdate.bin -y
in the efi/boot/startup.nsh file to
fwupdlcl.efi -F fwupdate.bin -y -allowsv
You’ll be able to apply the same firmware update a second time. I’m just blindly following instructions from earlier in this thread, but it got my version number to increment and I haven’t had any problems following that.
My search foo is bad… I didn’t see lots of folks are in the same situation
Sounds like battery status matters? My battery is kinda old. Do I need to buy a battery to upgrade my BIOS then?
It seems like I need to upgrade my BIOS to use the new battery, so that might mean a chicken/egg or hole-in-the-bucket kind of a situation?
I reset my main board status and it worked fine, but then after putting my computer to sleep and waking it up, it once again entered the boot loop. I also have deep sleep enabled. I wonder if deep sleep is responsible for this somehow.
Oh, that’s something I’m running too! And indeed, it could be happening after a deep sleep.
cat /etc/rc.local
echo deep > /sys/power/mem_sleep
For now I switched to s2idle instead.
I hope we can get some help on this one. I’ve made sure the USB stick is really FAT32 (not just FAT) and the battery is in charging state. I’ve done this several times now. The only anomaly I can find is that while the instructions say this:
4. System will reboot and install the update.
Mine just sits there with a prompt and I have to reboot it myself. So I wonder if there’s some step that isn’t happening.
Likewise, my system is booting and waking from sleep fine after going back to s2idle. I’m not in the same boat as everyone else, where the BIOS update isn’t going through, with the capsule update failing for some reason.
Same situation here, @David_Krause and @George_Coss. I’m trying to update from 3.06. First time through, script completed successfully, machine rebooted as expected, but I was still at 3.06 after reboot. Second time through, I ran into the “same version” error. After I modified the script to add -allowsv, the update re-ran successfully, but I got the cannot find a valid file system on boot devices error and machine did not reboot. Still at 3.06.
Worked for me on Linux. Thank you framework team!
Here’s my experience report with the Linux 3.19 upgrade:
- Updating from which previous BIOS release?
3.10
- How did the update go, any issues experienced?
After upgrade, the BIOS was still at 3.10.
Trying to run it again, it refused.
-allowsv made it retry, but after that completed it was still at 3.10.
Upgrading 3.10 → 3.17 → 3.19 worked without any complications.
I also tried upgrading directly from 3.07 to 3.19 and ended up needing to reset the BIOS (via completely powering down the mainboard and then reconnecting the coin cell and main battery) after a s2idle [deep]. Updating through the public versions, in order, (3.07, 3.10, 3.17, 3.19) seems to have worked.
Some potentially relevant information:
Linux kernel version: 6.6.32 (NixOS)
/sys/power/mem_sleep is set to s2idle [deep]
/sys/power/state is freeze mem disk
/sys/power/disk is [platform] shutdown reboot suspend test_resume.
Armchair analysis is that some bit of firmware is not getting updated with the 3.19 capsule updater but does get picked up by something along the 3.07 → 3.10 → 3.17 → 3.19 chain.
If there’s any other system configuration info that would be helpful let me know and I’ll try to provide it.
I can confirm the following works as well:
3.07 → 3.17 → 3.19
I did the upgrade to 3.17 using the USB key just like the 3.19 upgrade. For whatever reason, going directly to 3.19 fails, but going to 3.17 first works great.