I also booted from a USB stick, waited through messages that indicated startup.nsh running, then an automatic reboot. But sudo dmidecode -s bios-version still reports version 3.06.
Further information on the BIOS below. I find in my notes that I disabled “Enforce Secure Boot,” which appeared to be required to install Ubuntu Studio in December 2021. That seems unlikely to be relevant, but it doesn’t show up in the dmidecode output below.
$ sudo dmidecode --type bios
[sudo] password for odonnell:
dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: INSYDE Corp.
Version: 03.06
Release Date: 10/18/2021
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.6
Handle 0x0011, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Long
Installable Languages: 4
en|US|iso8859-1,0
fr|FR|iso8859-1,0
zh|TW|unicode,0
ja|JP|unicode,0
Currently Installed Language: en|US|iso8859-1,0
I put in the thumbdrive, it loaded completely, did it’s thing with the autorun script, rebooted – back into my old Grub with the same entries and an unchanged BIOS. Several reboots later there’s still no applied BIOS update.
I tried disabling the charge limit, so the BIOS sees that it is actively charging the internal battery, but the BIOS update still wasn’t applied.
@Michael_O_Donnell Does your last sentence mean, that your BIOS updated to the latest version after some reboots?
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.)
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.
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
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.
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.
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.
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
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.
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?
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.
