11th Gen Intel Core BIOS 3.19 release

[Vishwanath_E.V.S]

Also confirming that 3.10->3.17->3.19 upgrade worked for me, where the 3.10->3.19 direct upgrade didn’t work.
@Sapphire , does deep sleep work as expected for you after a successful 3.19 upgrade?

[Sapphire]

At the very least it doesn’t put the system in to a state where it fails to POST, from a quick check. I haven’t tried leaving the laptop in sleep mode for longer yet.

[Peter_Conrad]

AT LAST

Holy cannoli, I was finally able to upgrade my BIOS from 3.07 to 3.19.

I’m on Ubuntu 24.04 LTS, Framework 13 11th gen.

Here is what I did.

1. I upgraded from 3.07 to 3.10.
2. I tried to upgrade from 3.10 to 3.19.
   This was not so easy. For some reason, my USB wasn’t recognized as a bootable EFI disk anymore, although I’d been using it in my previous attempts. I had to go read F12 Bios Menu not recognizing USB Drive for bios update to 3.10 to solve that one. The TL;DR is that you have to set the boot order to First or Last. If it’s Auto, then you can’t even see it in the BIOS settings, much less the BIOS boot menu. Then, startup.nsh thought that I was trying to install the same version. I did the -allowsv thing and it didn’t help!
3. I upgraded from 3.10 to 3.17.
   This seemed to go OK. By this point I’d done a metric ton of reboots into the BIOS, reboots to try to boot from my USB drive, and multiple operations to change what versions of files were on the USB drive itself. It was time consuming and confusing, so I made sure to delete everything from the USB drive every time so as not to get part of one version and part of another.
4. I upgraded from 3.17 to 3.19.
   This time, it recognized that I was upgrading to 3.19 from a different version. Instead of the text/CLI progress that I’d seen before, I got a really nice graphical UI that said Please wait while we install a system update with a nice progress bar.

Now, sudo dmidecode -s bios-version reports 03.19 as it should. The takeaways for me are that you might have to go version by version, rather than jumping from 3.07 to 3.19, and that some of the upgrades might change BIOS settings such that you won’t see your USB stick in the boot menu.

[David_Krause]

After trying many things to go directly from 3.07 to 3.19, or even from 3.07 to 3.17, I followed the same sequence as @Peter_Conrad and am now running the 3.19 version.

I had secure boot enabled before trying, so I did have to disable secure boot in the BIOS, but other than that, the upgrade from 3.07 → 3.10 → 3.17 → 3.19 was a success using a FAT32 formatted USB stick. dmidecode confirms 3.19, and the BIOS screen seems to confirm the CMSE update, as well.

Really appreciate Peter posting his sequence.

Framework team could possibly help people out by suggesting to go one version at a time on the 3.19 release notes. I had not been keeping up with BIOS updates, but got an e-mail from 3.19, and tried to just jump ahead, which many of us tried to do, judging by the comments in this thread.

[David_Earl_Sparks]

11th Gen Intel - Ubuntu 24.04 - had BIOS 3.10 from a previous update, updated to 3.17 successfully, then updated to 3.19 also successfully.

[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?

[Paul_Schacht]

Thanks, @Peter_Conrad and @David_Krause for your detailed accounts. I too was finally able to upgrade incrementally (3.06 > 3.10 > 3.17 > 3.19). I re-enabled secure boot after upgrading to 3.17, since the 3.19 upgrade instructions didn’t call for disabling it. Agree that it would be nice if the general instructions recommended upgrading incrementally.

[Brian_White]

Deleted.

I started writing a post that I thought was going to be about a bios bug not saving settings, but it was a dead coin cell.

[Eric_Newbury]

I was on Bios version 3.07, tried to do the UEFI update to 3.19. It ran to 100%, then restarted. I checked the BIOS version and it was still 3.07. I tried booting to the thumb drive again and it gave an error saying it couldn’t migrate to the same version, which makes me think the update did run.

What am I missing? I checked dmidecode and booted directly into the bios to check the version. I’ve confirmed I used the correct version for my Linux and my 11th gen 13" framework.

[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!