I am having what I think is the same issue. I am running Fedora 40 (single boot but formerly dual-booted with Windows 11). My main partition is LUKS encrypted, but that shouldn’t affect boot or efi, right?
I’ve tried the official way, and I have tried your suggestions, so they may influence the result. I deleted OsIndications, but it appears to have regenerated.
It’s worth noting I got the usb-PD updates by running Startup.nsh after I typed FS1:, but the firmware wouldn’t install because Framework_Tool was not found (presumable because it is on FS0, the USB drive). When I ran FS0: and then CapsuleApp.efi winux.bin firmwarehdr.cap -OD FS1, I got some messages indicating that the UpdateCapsule contents were transferred to /boot/efi, and in fact there is a new /boot/efi/EFI/UpdateCapsule folder (yes, EFI is repeated, first lowercase, then capital), and it contains firewarehdr.cap and winux.bin, but after it transferred them, without any visible error, it would just boot my computer into grub. I don’t know how to finish the firmware install.
Anways, answers to your questions:
efivars (I don’t know what piping to xxd. file is)
I deleted them (along with the OsIndications efivar) and tried again. Same as before. When the computer rebooted, I was still on 3.04, and the firmwarehdr.cap and winux.bin files were recreated. Linking a video to show what happened. Like before, there were no error messages. Just a near-instantaneous reboot.
Could the issue be some sort of interruption? Is it possible they have been copied over, but not yet renamed when it reboots? For your information, I pressed no other buttons. I would think if it had to stop because of an error or lack of space, it would show a panic message before the reboot, but while it goes by quickly, I don’t think I see an error message.
Please keep this thread on topic. The aim of this thread is for people to report successes/issues with updating to this BIOS release through the various updating methods. This will allow the team to make improvements if necessary and allow others to receive support.
I’m using GDP G1 and it was working fine with 3.06. It doesn’t work with 3.08. There were many NixOS updates before I got to this eGPU after 3.08 update, so I’m not absolutery sure that the BIOS update is the reason.
Updated with 3.08d through UEFI + updated retimers. eGPU still doesn’t work.
[ 5.010315] pcieport 0000:00:07.3: pciehp: Slot(6): Link Down
[ 5.010324] pcieport 0000:00:07.3: pciehp: Slot(6): Card not present
[ 5.010335] pcieport 0000:7e:04.0: Unable to change power state from D3hot to D0, device inaccessible
[ 5.010959] pcieport 0000:7e:04.0: Runtime PM usage count underflow!
[ 5.010987] xhci_hcd 0000:82:00.0: remove, state 1
[ 5.010996] usb usb6: USB disconnect, device number 1
[ 5.011000] usb 6-1: USB disconnect, device number 2
[ 5.011654] xhci_hcd 0000:82:00.0: USB bus 6 deregistered
[ 5.011663] xhci_hcd 0000:82:00.0: xHCI host controller not responding, assume dead
[ 5.011730] xhci_hcd 0000:82:00.0: remove, state 1
[ 5.011735] usb usb5: USB disconnect, device number 1
[ 5.011737] usb 5-1: USB disconnect, device number 2
[ 5.012150] xhci_hcd 0000:82:00.0: Host halt failed, -19
[ 5.012153] xhci_hcd 0000:82:00.0: Host not accessible, reset failed.
[ 5.012547] xhci_hcd 0000:82:00.0: USB bus 5 deregistered
Could you try going to the F2 bios setup menu, and go to save and exit, apply optimal defaults, and then try again? This should reset all BIOS settings to default. There may be some strange state held that this could reset and allow your update to work correctly.
Did the update including retimers. I’m not sure how to check retimer version, but bios version did update correctly. When updating the bios, I originally had my laptop unplugged but at 100% battery. It updated the firmware fine, but then when it went to update BIOS, it would give me the Framework bootup splash screen with a message akin to “Applying system upgrades” (I don’t remember the exact words) and immediately turn off.
I had to make sure the laptop was plugged in for the bios updates to work. It sure got REALLY HOT when updating the bios I gotta say, and it took a long time, but eventually it did finish.
Updating the retimers was considerably less dramatic
Now that FW has officially released the Windows driver for the Fingerprint Sensor in the FW13 AMD driver package (dated 2024-04-02), can we get that as well for 11-13th gen boards?
As per Framework it fixes security issues and the fingerprint sensor to our knowledge is exactly the same across all FW13 variants and as a USB device is independent of which CPU/mainboard you have in the system.
13th gen driver package has remained on .180
12th gen driver package has remained on .170
11th gen driver package has remained on .140
Hello, can somebody help me with updating the bios?
I run a single boot Arch linux. I’ve formatted an usb drive to fat32 on another Windows laptop and extracted the zip contents. Both Windows on the other laptop and Arch recognized the drive. The drive is also recognized in the bios of the Framework laptop. However, when booting the system and pressing F12, the usb with the update files doesn’t show up! Whatever I do, it’s not there. What can I do?
If the drive is just FAT32, then there probably isn’t any EFI partition or system files to boot from on that partition. Creating an EFI partition and placing files for EFI booting on that partition would be the first step in allowing it to become bootable, I believe. Others would have to chime in with further details, since I’ve not updated a Framework’s BIOS through Linux.
There does not need to be an EFI System partition. Not on external USB drives.
If it’s not recognized as bootable the BIOS does not like sth. about it. Maybe the folder structure, maybe the way it is partitioned, maybe the stick itself.
That’s interesting, I didn’t know that. I thought either an EFI partition or an older style BIOS boot configuration would be required in order to boot from USB media. If there’s no boot partitions, I’d think it wouldn’t be bootable unless a boot loader on the SSD is preset to boot from the USB media as one of its options.
My understanding is that the F12 boot menu would search for bootable media appropriately set up to be bootable, though I could be wrong.
I was being very silly… I copied the folder that got extracted from the zip, but should have only copied the contents of that folder. After trying it with that it was a few minutes easy work.
I have not looked at the underlying standards. And there is some variance from BIOS to BIOS (especially the situations that make them hang or skip the device. For example an old notebook would completely hang in BIOS if the FAT32 partition was not clean unmounted).
But on external USB sticks, which are technically meant to be without partition table and therefore only 1 partition, it uses just the file path efi/boot/Bootx64.efi. That, on a clean-unmounted FAT32 partition should be enough for every UEFI. Also what is done from CDs (like Windows ISOs) if they boot via UEFI. Although depending on the BIOS this path-based mechanism may cease to work if you put a partition table or multiple matching partitions on the drive, as then, you could have an EFI System partition.
On my 12th gen, I can use a USB stick with GPT partition table and 3 FAT32 partitions, each of which is offered as bootable by that path-mechanic alone (while my desktop PC will only pickup the first partition and ignore the other ones).
The logic I understand is: for internal drives, the boot entries stored in UEFI are responsible. Although they are probably mandated to only point to EFI System partitions. For occasional, external drives, you really cannot have boot entries setup, as that would render the whole purpose moot. And I don’t think any assistant to manually add boot entries from the BIOS setup or autodetect them is standard. So for external drives, BIOS is supposed to look for FAT32 partitions with bootable EFI binaries on them at a path, specific to the architecture (so you could have arm, x84_64 bootable etc.). Like I said, I do not know if this is only officially for non-partition-table devices. It might. But in practice it also works for GPT partitioned drives. Although the modern UEFIs tend to have some auto-BS, where they look for EFI system partitions on all drives and automatically create permanent boot entries in the BIOS (which will remain even if the drive no longer exists and need to be cleaned up manually. Horrible behavior!).
I am in the same boat (more or less) and also tried these various ideas (setting to optimal defaults, removing OsIndicators). Interestingly, when OsIndicators exists I get the issue from @Adonnen’s picture of:
Get Boot Next Data Fail. Status = Not Found
CapsuleApp: cannot find a valid file system on boot devices. Status = Not Found
CapsuleApp: failed to update capsule - Not Found
But, after deleting OsIndicators, I do not get that error. However I get what everyone else has been reporting:
Found EFI system partition on Boot0001: EFI Hard Drive (<some stuff I am omitting>)
Succeed to write winux.bin
Succeed to write firmwarehdr.cap
But then it just boots into my OS, no updates or anything! And then OsIndicator exists again.
My BIOS is currently 3.04, I have a batch 2 12th gen.
(P.S. I hope I didn’t mistype anything in the code snippets above, I am trying to transcribe from a blurry video I took of the process haha)
EDIT: I should note that for me it so happens that FS0 is my NVMe drive and FS1 is my USB stick.
Been trying everything mentioned here for the last few hours. I’m on 3.04 as well as nothing I do has worked. The best I’ve gotten is a few quick reboots and then back into fedora. I get the same two files in the EFI CapsuleUpdate folder, even after I force the updater script to use the nvme drive as FS0 or FS1 depending on the partitions on my USB drive. I tried plugged into power and unplugged, I tried deleting the osIndicator files. I tried letting the script run and trying it manually. Nothing except reboots back into fedora and dmsicode still says 3.04. One of my retimers is 310 and the other is 2**.
At this point, I’ll just wait for the official release for Linux. The other option would be to buy another nvme drive and install windows just to do the update and the swap drives back. I should add, my laptop works just fine, I was hoping the bios update would have some low-level performance and security and power utilization updates. Looking forward to seeing it and would rather not brick my laptop.
