11th Gen Intel Core BIOS 3.19 release

[Arnix]

Hi Eric.
It seems you would need to do the updates in order, i.e. 3.07 → 3.10 → 3.17 → 3.19 (see this post)

[rstat1]

I also noticed this when I just did the update. Also from Fedora 40

The EC still reports its previous version too. Only thing that appears to have updated was the ME.

[Eric_Putney]

I’m seeing the same CapsuleApp errors, am trying to update starting from 3.17. I have added the -allowsv flag, since I’ve attempted this a few times now. This is on arch.

@Paul_Schacht

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.

@Richard_England

Has anyone had difficulties going from 3.17 to 3.19? I have a Gen11 running Fedora 40. The USB thumbdrive creation appears to be no problem. I can boot from it and it starts the BIOS update and appears to complete and reboots. But when I check the BIOS it still reports 3.17.
If it matters this is a 13 inch system.

Has anyone else experienced this?

In full, this is what I get:

FW Update: [100% (1)] Do not Interrupt
FW Update completed successfully and a reboot will run the new Fil
FSO:\> CapsuleApp.efi winux.bin firmware_hdr.cap -OD
CapsuleApp: creating capsule descriptors at 0x439E4B18
CapsuleApp: capsule data starts at 0x3EA4C018 with size 0x45422
CapsuleApp: capsule block/size 0x3EA4C018/0x45422
CapsuleApp: creating capsule descriptors at 0x439E4E98
CapsuleApp: capsule data starts at 0x30840018 with size 0x2208904
CapsuleApp: capsule block/size 0x30840018/0x220B9D4
Error: Cannot find a EFI system partition!
CapsuleApp: cannot find a valid file system on boot devices. Status Not Found CapsuleApp: failed to update capsule - Not Found
FSO:\>

It’s clear that the CSME has sucessfully updated to v0:15.0.42.2235, but the bios dmidecode output is still 03.17.

I suspected that @Michael_O_Donnell was on the right track with the updater getting confused by inconsistencies

@Michael_O_Donnell

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.

for example, if the CSME install succeeds on the first try but EC/BIOS fails, then later EC/BIOS updates will fail because it’s on an unexpected CSME version. I tried reinstalling 3.17 to revert my CSME (not even sure if that packages a CSME, actually) and then upgrading to 3.19. But I had the same result. Stuck on 3.17.

I’ve tried in various states of battery life + charging/no charging, no dice. Any suggestions?

[DHowett]

@Eric_Putney

Error: Cannot find a EFI system partition!

How much space is available on your EFI system partition? The EFI shell should display it if you run dir fs0:\, or you can check it from your OS.

You’ll need at least 64MB free. If you do not have that, the updater may not consider the volume viable.

[Eric_Putney]

@DHowett

You’ll need at least 64MB free. If you do not have that, the updater may not consider the volume viable.

Thanks for the tip, I’ll check that next time I sit down

[DHowett]

You can also try to run CapsuleApp -F (no other arguments!) to see what it thinks about your available volumes.

If it doesn’t find any at all, then you have a slightly different problem… you’ll want to verify that the partition type in your GPT is C12A7328-F81F-11D2-BA4B-00A0C93EC93B or, shorthand, EF00. You can do this with gdisk on Linux (gdisk /dev/nvme0n1 then p), or Diskpart on Windows (diskpart, sel dis 0, sel par 1, detail par – assuming that your ESP is partition 1). If it’s not, you actually don’t have an ESP. This could break any number of tools.

[Richard_England]

On Fedora 40 I downloaded the zip file again to a new thumbdrive and unzipped it and this time it and after reboot I was on 3.19. The update process the second time showed a progress bar during update but the first time did not. It simply rebooted.

Check your hardware and downloads.

[Jared_Mauch1]

@Eric_Putney

I suspected that @Michael_O_Donnell was on the right track with the updater getting confused by inconsistencies

@Michael_O_Donnell

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.

for example, if the CSME install succeeds on the first try but EC/BIOS fails, then later EC/BIOS updates will fail because it’s on an unexpected CSME version. I tried reinstalling 3.17 to revert my CSME (not even sure if that packages a CSME, actually) and then upgrading to 3.19. But I had the same result. Stuck on 3.17.

I’ve tried in various states of battery life + charging/no charging, no dice. Any suggestions?

You may want to try the Linux updater I found and tossed up so you can just do the CSME. That’s what I did for my device. There’s info posted above where to find the zip I shared.

I do wish that Intel would post those directly for the devices as there’s different tool suites based on chipset, and the one I posted matches the hardware.

[Eric_Putney]

@DHowett

You’ll need at least 64MB free. If you do not have that, the updater may not consider the volume viable.

I have >256 MB free, so that’s all good

@DHowett

You can also try to run CapsuleApp -F (no other arguments!) to see what it thinks about your available volumes.

Ah yes, here’s the problem. No EFI System Partition found!

@DHowett

If it doesn’t find any at all, then you have a slightly different problem… you’ll want to verify that the partition type in your GPT is C12A7328-F81F-11D2-BA4B-00A0C93EC93B or, shorthand, EF00. You can do this with gdisk on Linux (gdisk /dev/nvme0n1 then p), or Diskpart on Windows (diskpart, sel dis 0, sel par 1, detail par – assuming that your ESP is partition 1). If it’s not, you actually don’t have an ESP. This could break any number of tools.

So indeed, I’m on MBR and so I don’t have a GPT. I swear I haven’t had to think about MBR vs GPT in a long time, but here I am again. Is there a way I can update with MBR, or a non-destructive way I can switch to GPT (on Linux/Arch)

Edit: I’ll give this a shot after backing up: GPT fdisk - ArchWiki

[Eric_Putney]

@Jared_Mauch1

just do the CSME

Thanks! Though I think I have the opposite issue, so far only the CSME has been updated. Appreciate your prior work though

[Eric_Putney]

@Eric_Putney

Edit: I’ll give this a shot after backing up: GPT fdisk - ArchWiki

Success! I booted into a gparted live usb to pad the last partition to leave room for the GPT, and then booted into a live arch iso to convert my disk from MBR to GPT. Afterwards, I ran the BIOS update utility. It silently failed the first time since I wasn’t charging, but after I plugged in and tried again I got the green progress bar and it successfully updated to 3.19. Thanks @DHowett for your help!

[DHowett]

@Eric_Putney

Thanks @DHowett for your help!

Glad it worked out!

[Nicholas_Weininger]

FWIW, I just did this upgrade and I think the knowledge base instructions should include the following explicit steps to avoid traps for the unwary:

1. when unzipping the bios zip file to your USB drive, make sure to preserve directory structure, else your resultant disk will not be bootable.

2. when updating the bios make sure your laptop is plugged in to charge, otherwise the system update will silently fail to run and you will be stuck on the old bios version.

Those two tips would have saved me the better part of an hour of frustration just now. Thanks!

[Jonathan_Gagnon]

Getting error 404 when trying to download bios 3.19 at https://downloads.frame.work/bios/Framework_Laptop_11th_Gen_Intel_Core_BIOS_3.19.exe

[TheTRUEAsian]

Just tried it and had no issues downloading it. Perhaps try another browser?

[Destroya]

I had no issues downloading it, can you please check again?

[August_Pamplona]

Having to do multiple updates to go from 3.10 to 3.19 is certainly not something that I expected to need to do.

Also, it seems like as the updating process is meant to update multiple things (described as the OP as “a bundle of updates”), some can succeed while others fail (I know this because trying the 3.19 update, directly from 3.10, a second time recognized something as being the same version). It would be good to know what the expected result is when we are done beyond knowing that, on Linux, sudo dmidecode -s bios-version should output 03.19 (or whatever the procedure is to get this information on Windows).

How many other things does the update change, where/how do we check to verify them (can you) & what are expecting to see to confirm that they were properly updated?

[byteskeptical]

For anyone having issues with the USB method try disconnecting your SSD prior to booting the usb and running the update. There is some naive logic in the disk detection code.