Well i tried your workaround since i have exactly the same problem as @alko89 over here but it sadly didn’t work for me, still same result / error. Still worth a try i guess.
Oh !
Was it the same error message ? “cannot find a valid file system” ?
You may try to tick “boot” and “esp” boxes in gparted partition.
With this method, it worked for me, even though it did not flash retimers.
yupp, “cannot find a valid file system on boot device”
And i tried esp and boot flags to no avail. Did you use the 3.08d update or the older variant including the retimer updates ?
Did you use an usb3 stick?
Yes. I used the 3.08d. The updated link from the first post here.
I also tried the 3.06, but could not flash either.
It did not work and i tried many different options. And then, this one worked. I tried on a Kingston Datatraveller 64GB, with a USB-C to USB3 adapter, on left bottom port. USB-C charger on left upper port.
I’ll try again the retimer update when I’m back on home.
Updated without issues, also updated retimers, and everything ok so far.
dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.4 present.
55 structures occupying 4083 bytes.
Table at 0x3F0A7000.Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: INSYDE Corp.
Version: 03.08
Release Date: 12/25/2023
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 16 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.8
1 Like
Are we ever going to get Bios update for Framework 13 Intel Gen 12 for LINUX (not Windows), it was promised from 2022!?
A post was merged into an existing topic: Introducing the new Framework Laptop 13 with Intel Core Ultra Series 1 processors
I am not looking for Windows , but for Linux. And not beta version! This is the official page Framework Laptop BIOS and Driver Releases (12th Gen Intel® Core™)
And it is not irrelevant to this topic as old customers are abandoned while they keep releasing new products!
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