It is irrelevant to that thread, and has been moved for that reason.
3 Likes
Hey Lamy, EFI update was marked as beta less than a week ago and our team is working hard to solve issues reported on this thread. We had a similar update for Framework Laptop 13, 11th gen Intel Core, which left the beta phase two days ago. Please feel free to use the beta version and report if you have any issues. Alternatively you can wait for that update to leave the beta phase, we will be announcing that here. Thanks for your patience.
3 Likes
I try to install the 3.08d Update. Same error as alko89: cannot find a valid file system on boot devices
SYS CONFIG: 12th Gen IntelĀ® Coreā¢ i7-1260P
RAM: 2x16 GB Crucial RAM 16GB DDR4 3200MHz CT16G4SFRA32A
SSD: SAMSUNG 980 PRO NVMe 1TB
Wi-Fi: AX210
External Devices/Other: no
EXPANSION CARD TYPES: 1xUSB-C (With Power), 1x USB-A (With Boot Stick)
BIOS VERSION: 3.04
OS VERSION: Ubuntu 22.04.4 LTS
1 Like
Thanks for your reply. But it would unethical for the company to ask users to try the Beta version of the BIOS, as when 3.06 Beta was released I tried it. And the final version was never released. Framework quietly switched to 3.08 BETA without giving any explanations and risks and security vulnerabilities that people might have been exposed to. Now, I donāt know what risks my PC has been exposed to since 2022! Several people have suffered due to this unethical behavior from 2022.
1 Like
This isnāt unethical. You have the choice of installing the BIOS update using the BETA .EFI updater or waiting until it is officially released. If there are issues, then itāll undergo further development and be re-released. For clarification, the 3.08 BIOS update is now official through the Windows install method. Only the .EFI update method is currently in BETA.
Frameworkās procedure for BIOS updates is that they are first released as a BETA for community members to assist with testing (if they chose to do so). If there arenāt any reported issues within 2-3 weeks, it moves to official release. You can see all the vulnerabilities that have been fixed in the 3.08 patch notes
4 Likes
Now I wonder if it makes a difference if the ESP is mounted at /boot or /boot/efi.
On the other hand, as far as I remember, both officially supported Linux distributions use ``/boot/efi`, so thatās what the EFI updater was probably tested onā¦ so better ignore that idea.
Knowing what (if anything at all) is copied where (hardcoded? ESP? thumbdrive?) during a successful update might make troubleshooting easier.
+1
2 Likes
That would imply your team is capable of delivering a BIOS update that doesnāt have any issues.
He isnāt a Framework employee but a volunteer moderator. He is not directly responsible for BIOS updates.
4 Likes
I for one do understand the frustration regarding the rocky road us Linux folks have for updates, more so since Iām back on Linux after needing to use Windows for school. If we are going to be making complaints, letās at least make sure we are talking to the correct people. Iām seeing progress from FW and am still cautiously waiting before I hand over any more of my money myself but I just want to say I understand the frustration. EFI is still touch and go and needs improvement in delivery but FW is trying and they are putting money and labor into improving things for us. I donāt know when things will be smooth going for us but I sure hope itās soon.
4 Likes
Why would that matter? The UEFI only sees the EFI System partition and its contents. There are regulated paths within that ESP where the UEFI may look for as of yet unknown executables (that is how USB sticks are recognized as EFI-bootable. By a FAT partition that contains /efi/boot/Bootx64.efi). UEFI can neither mount your Linux partition (at least it should not) nor does it need anything from it. The bootloader is on the EFI partition and has the job of finding all other partitions it needs and read from them whatever it needs to continue booting the OS of your choice.
CapsuleApp.efi is instructed to copy the capsule files to āTHEā ESP partition. In the previous 3.08b EFI updater this was hardcoded to fs0, whatever fs0 happened to be on your system and it failed when fs0 was no ESP partition.
The 3.08d updater instructs CapsuleApp to choose automatically. CapsuleApp as an option -F to dump all ESP partitions it found and the one it chooses will be among them. Perhaps it does not recognize any of your partitions as valid for some reason or it recognizes more than one and is confused / makes the wrong choice. Creating an ESP partition on the USB stick itself should not be needed, as any sane system running from the NVMe should already have an ESP partition.
Whether the update works from an ESP behind a USB device, I do not know. It might not since that is not a typical use case. So I would suggest checking what ESP partitions CapsuleApp finds, to investigate further why the automatic choice might fail.
Edit:
Looking at the source-code of CapsuleApp (current master branch, so may be different if the CapsuleApp used was built from older sources) seems to base its automatic choice of ESP off of wherever bootnext points to. I think that should be your default boot option as configured in the BIOS. But if that makes the difference you may want to double check that.
Edit2:
Previous answer was incomplete. It does look at the bootnext option. But that is not typically expected to be set. In that case it iterates over all boot options for the first one that uses an ESP.
Oh, and the files are written to \efi\UpdateCapsule\
/Edit
You are aware that Framework has established a proud history of not meeting the various estimates that they gave for progressing a firmware version to release and yet remaining completely quiet and not even confirming any issue that is a blocker to a release? So calling this a āprocedureā is a bit of an overstatement.
The last timeframe they announced for 12th gen was those 2 weeks for the 3.08 updater from January. And there were only crickets for months and then a hastily released version without announcement in this thread of the wrong installer. The 3.06 beta before stretched this uncertainty windows to like a year.
And I also believe I have shown that Frameworkās release notes for firmware updates can neither be relied upon for solved issues nor for known issues. They only ever seem to reflect some arbitrary snapshot in time and are never kept up-to-date with what is actually known. So the first part of your post has also been disproven by Framework themselves on this very updateā¦
5 Likes
It shouldnāt. But believe it or not, Iāve encountered situations where other operating systems canāt write their bootloader (or whatever you want to call it) to the esp because they expect an efi directory on the esp (cd efi) and only then add their respective subdirectory (mkdir -p whatever). So, have Windows installed or mount your esp in Linux (your main OS) at /boot ā efi directory almost certainly exists on the esp, mount it at /boot/efi (and donāt use Windows) ā probably no efi directory directly on the esp. I admit thatās an edge case but having had to troubleshoot that situation for several hours some years ago made it stick in my mind.
Could you point me to the source code? It seems Iām too stupid to find it in the framework github repositories.
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
Its not Frameworks code. Its part of the EDK2 where the entire EFI Shell is also from.
I have not researched this fully. But to my knowledge it is convention to have that efi folder on the ESP. But it does not actually matter, because any OS is supposed to manage its own UEFI boot entry that just contains the path to whatever file on the ESP it wants to have booted. So as long as the boot entry matches the path inside the ESP that was actually used its fine.
And the only actually necessary path is efi/boot/bootx64.efi as that is what is autodetected by the UEFI on removable devices such that they do not need to have a boot-entry preconfigured. And such removable storage also does not need an ESP partition, but just any FAT partition with a compatible UEFI executable at that path (which means only one executable per partition and not multiple as possible in an ESP).
UEFI Boot Entries
BootOrder: 0002,0001
Boot0001 UEFI OS HD(1,GPT,41ee612a-d2ca-4999-bf03-f1e0aeb26936,0x800,0x12c000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0002* CentOS Linux HD(1,GPT,41ee612a-d2ca-4999-bf03-f1e0aeb26936,0x800,0x12c000)/File(\EFI\CENTOS\SHIMX64.EFI)
2 Likes
Hey @alex_fixeurs sorry for late reply, was fully occupied by work. Unfortunately it doesnāt work for me either. I have also tried formatting the drive as GPT and create an EFI System partition on the drive with the same result.
I also tried using different ports on left and right as you mentioned to @Gronkdalonka . I used the USB-A adapter. 
1 Like
Hmmm, why would that matter? The BIOS update is happening from the USB stick and donāt think it really touches the OS system partition where fstab file is saved. If it does for some reason, I have ESP mounted on /boot.
EDIT: nwm read through the rest of the comments 
1 Like
Thanks so much for the screenshot. It is helpful.
Looking at your screenshot and the error output, I think you can manually recover this by doing the following, but if you can run the debug steps I listed below first to collect information for us it would be helpful. .
- when you get to the terminal, hit esc to drop to the shell.
- look at the top of the screen. You have your internal NVME drive as FS1. And your usb drive as FS0. (You can see they mention the device type in the path)
- type FS0: to switch to your usb drive.
- type: CapsuleApp.efi winux.bin firmwarehdr.cap -OD FS1
This will force installing the capsule on your NVME EFI partition.
Technical Background is as follows:
The firmware update process is as follows:
- When the capsule update is installed, it is copied to the ESP partition of the boot drive. The system does a cpu reset, and then applies the update early on in the boot process, so it needs to be saved to the disk so it is not lost during cpu reset. The capsule can be stored on any disk with a fat32 partition, but we have found some drives are not recognized early on in boot, so the best partition is the one on your NVME drive.
The early detection of the boot drive is critical to the previous 3.06 updater we released, as it required rebooting the system several times, and having the usb drive be recognized so the system can run the next steps of the update. However based on customer feedback we found that many people have usb flash drives that take longer to initialize, and will not be recognized. When this happens the bios will clear the boot variable as the drive is not found, and then immediately boot to the OS part way through the update.
We found the EDK2 updater allows us to chain several capsules together to install them all at the same time, which gets around the problem of the usb drive not being recognized.
Based on the error message, it looks like the updater is getting a little confused as it seems you have the EFI variable BootNext defined. But in your case the BootNext variable is pointing to an invalid partition.
The capsuleapp will check if the variable OsIndications is set, this is a special variable which indicates to the bios that an update should be applied. If this is set the updater will check if the variable BootNext is set, and use this to stage our bios update on the same partition as the current pending update. If these are not present/set then the updater will look at all the partitions on your system, and try to select the best one.
I think you might be hitting a case where there was a failed update, or linux installed an update (such as DBX) and then something went wrong and this variable was never cleared.
I would be interested in getting these variables. In Linux, you can look at the variables as a root user in /sys/firmware/efi/efivars
It would be interesting to see your Boot* variables, BootNext, and OsIndications variables. (They will all have a long string -GUID on the end of the variable name). OsIndications is binary, so you can get it by piping to xxd. file
Could you gather the contents of your ESP partition by running as root: ls -R /boot/efi/EFI/
Could you also see if there is a folder in your usb drive you used to update that is /EFI/CapsuleUpdate/
I would suggest trying the following to try to recover if the method above does not work.
- boot to your bios setup menu (F2), and then go into the setup menu->save and exit. Load optimal defaults. then reboot and try to install again.
- you could try deleting the OsIndications variable by removing the associated file /sys/firmware/efi/efivars/ in linux and then try installing again.
7 Likes
Though I donāt have an intel Framework, I really like all this technical information. This can undoubtedly help other end users with their updates, too. All of this information is good to know.
2 Likes
Is there any work being done so that the firmware update can one day be done through LVFS ?
I have been waiting for it since I want to get my hands on the newer battery because I donāt want to meddle with a potentially messy beta update procedure but if thatās never going to happen, Iād like to know.
1 Like
Btw. Everything, except ME firmware could / is already updated through LVFS.
Framework could make 3.08 available via LVFS. And the only thing missing would be that you need to manually run an executable for the ME firmware update (maybe even the one used on the EFI installer that we already have). They could do that immediately if they wanted.
The Windows updater essentially already does this, it can just automate both of those steps together, while LVFS does not allow this (shipping the update through Windows update like most vendors do might also not be available for the same reasons as for LVFS).
And the ME problem seems solved for 13th gen that can update ME firmware with capsules, so that additional installer is no longer needed. Whether it is sensible to backport those fixes to 12th gen and how it updates itself I do not know. It is most likely possible, but there may be technical reasons to discourage touching this, depending on whether that is part of a recovery solution to recover from interrupted/broken updates.
4 Likes
Thank you for providing this info. I ran into the same problem. Iām now good to go.
