I had similar problems with the beta release. The update completed successfully after I completely reformatted my USB drive, re-extracted the update files, and then booted off it again. (I hadn’t fully formatted the USB drive before my first try, and so I’d assumed this was my fault for not doing that.)
1 Like
No. After several reboots, I still see version 3.06.
I noticed that you mentioned the battery “actively charging.” I see that the LVFS instructions for update to 3.17 mention that there may be no update when the battery is completely charged. I can’t find any such mention for UEFI boot updating to 3.19: Framework Laptop BIOS and Driver Releases (11th Gen Intel® Core™)
I generally keep my laptop plugged in, and the battery topped off, so, if that can interfere with the UEFI boot update to 3.19, that could be my problem. Later today I will try running the battery down a bit.
(May 29, 15:15 MDT) I ran the battery down to 72%, plugged in, verified that it was charging, rebooted without the USB stick. The boot looked normal, no indication of any sort of update, dmidecode reports that I still have version 3.6 or 3.06 (I noticed that two different reports formatted the version number differently, but I think they refer to the same version).
My update left me at version 3.06 although I used a USB stick freshly formatted to fat32. If the warning that the battery must be actively charging, mentioned for LVFS update to 3.17 but not for UEFI boot update to 3.19, is still relevant, then perhaps on your later try you had a lower battery status.
I hope that someone from Framework will write soon to clarify whether battery status is important.
Very similar problem to what Michael O. is reporting.
My 11th gen is on BIOS 3.07 running Ubuntu. Followed the directions to update to 3.19 via USB stick, the UEFI updater went through the update process and then rebooted.
The BIOS screen and running dmidecode in Ubuntu both show I’m still on 3.07. When I try to run the updater again from the USB stick for 3.19, it tells me it can’t update to the same version it’s already on.
Is there something simple I’m missing here?
2 Likes
Linux
I tried to do the update from 3.17 to 3.19. This didn’t work the first time. Running the second time didn’t work as it said the versions matched but reports like dmidecode disagreed.
The bios update did generate a error log. This tells us that you can force the update by adding a flag.
Add -allowsv to <usb drive>/efi/boot/startup.nsh in line fwupdlcl.efi -F fwupdate.bin -y
So:
fwupdlcl.efi -F fwupdate.bin -y -allowsv
This will bypass the version equivalence check.
This worked for me, the installation with this extra flag succeeded. After I started the upgrade a reboot happend with the message that they are updating the firmware, after which a nice green progress bar appeared.
At the end it rebooted into the os and now dmidecode reports 3.19
1 Like
Thanks for the suggestion. I was able to get the update to re-run with fwupdlcl.efi -F fwupdate.bin -y -allowsv.
However, I still got an error on CapsuleApp.efi winux.bin firmware_hdr.cap -OD with error cannot find a valid file system on boot devices. Status = Not Found.
1 Like
That sounds good, BUT. I wonder about the “CSME” update. Presumably, fwupdlcl.efi runs while the system is up, which sounds similar to the LVFS update. Warning from the instructions:
Blockquote There will not be an LVFS update for this specific release because it has an Intel CSME update, which can’t be delivered through LVFS. Use the UEFI Shell update method instead for this release.
So, I worry that the main BIOS is updated, but not the CSME, which perhaps can only be updated during a boot.
Later today, I will try running the battery down and then rebooting while it is charging. That should illuminate things, but it will take time.
My initial upgrade from 3.17 to 3.19 was done at 24% battery while not charging. When doing my second try with the extra flag, I was charging.
It seemed to me that everything was done pre-GRUB and as such was happening in the UEFI environment.
I didn’t have any new logs on my usb disk or messages like George_Coss
Trying with the -allowsv option, I am in the same situation as George. The FW update completes, but then the UEFI loader stops with the CapsuleApp errors. Rebooting and I am still on the previous version (3.07).
Also, I thought maybe I could get from 3.07 to 3.17, but the LVFS update procedures tell me there are no updates available.
In the absence of a good authoritative summary from someone who knows, I am stuck with a lot of speculation.
I don’t see “fwupdlcl” on my system, and I’m not sure when and how George_Coss and Tarik_Welling invoked it. I am reluctant to try it without understanding more.
The FW update completes, but then the UEFI loader stops with the CapsuleApp errors.
I have no real knowledge, but I wonder whether this could have to do with fwupdlcl updating the BIOS code, but not the CSME (I have no idea what CSME stands for) and creating an inconsistency. I will wait for some clearer info before trying anything else.
Same experience as others:
- Downloaded the 3.19 EFI updater.
- Extracted the contents to a usb drive, rebooted with drive plugged in
- Pushed F12 on reboot to select the EFI usb drive
- The update ran, apparently successfully, computer rebooted
dmidecodecommand, invoked as Framework recommends, showed a bios of 3.07 instead of the expected 3.19.- Rebooted to run the bios update again, but was given a “same version” error.
- At the open prompt, I ran the previously executed command with the
-allowsvoption, as it sorta recommended. - That process ran to apparent successful completion.
- Rebooted into Ubuntu, and the
dmidecodebios version of 3.07 remained.
1 Like
Linux upgrade worked great:
- Get a spare USB drive.
- Format it (I used gdisk)
gdisk /dev/sda # replace with your device, this is interactive
o # nuke with new partition table
n # new partition
EF00 # use the EFI partition code
w # write to disk
- Create the FAT32 partition, e.g
sudo mkfs.vfat -F32 /dev/sda1 - mount it somewhere, e.g
sudo mount /dev/sda1 /mnt - download the zip and extract files somewhere
- move files to the mountpoint
- reboot and select USB drive to boot from (spam F12 on boot)
BIOS Information
Vendor: INSYDE Corp.
Version: 03.19
Release Date: 05/29/2023
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 12 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 3.19
2 Likes
Would be great to see the upgraded CSME blob with a final 3.19 release. I’m also willing to help with the 3.20 testing if that’s possible
we are going to have a 3.20 release soon. And CSME update is coming with this, as well as wifi 6E band support.
13 Likes
Hey! I updated to the newest BIOS version, (3.19) yesterdays evening. After the extraction the firmware update and putting it on an USB stick, the update ran and rebooted to my VoidLinux operating system. I haven’t looked into the “did not update correctly” situation, I saw in other threads.
Seemingly at that point the update worked. I haven’t checked if the version actually updated.
I continued working for that evening, but when I booted it this morning, the notebook got stuck in a apparent boot loop, without showing anything on the screen. I’m also not sure if I put it into sleep, shut it down or just let it drain the battery for a night. Is there anything I can do to solve this situation?
The bootloop looks like the following:
- pressing the power button
- button lights up, fan starts spinning. with varying speed, so it feels like the temperature control is working
- power draw ~20-30W
- ~1 minutes nothing happens
- button light turns off
- power draw 6W
- ~5 seconds, button lights up again, cycle restarts
I can it stop cycling by long-pressing the power button, but I interact with the system in any other way.
- OS: VoidLinux, up to date
- Model: Framework 13, 11gen
–Enno
Folks, I ran through the instructions here Framework Laptop BIOS and Driver Releases (11th Gen Intel® Core™) to upgrade my firmware from 3.07 to 3.19 using the EFI shell method. (Copy everything to fat32 usb key, let run to completion, etc.)
Everything seemed like it worked… the file was verified and the EFI shell upgrade completed. Rebooted just fine, but everything says it’s still 3.07. (Both the bios screen and the ‘sudo dmidecode -s bios-version’) I can reboot into ubuntu just fine… just didn’t upgrade I guess?
If I try to run it again by booting the usb key it just says already installed. I feel like I missed a step but not sure what. Any ideas?
1 Like
The instructions seem to say that a CSME update is already included in the 3.19 release:
There will not be an LVFS update for this specific release because it has an Intel CSME update, which can’t be delivered through LVFS. Use the UEFI Shell update method instead for this release.
Is there a way to check the CSME version?
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.