If his worked for you, then the theory from @RandomUser that that the BIOS update requires space on an internal drive can’t be right. So either the EFI script doesn’t need an internal drive but will corrupt it if present OR @Jake_Bailey is correct and its simply the NVRAM being cleared and only partitions with an EFI fallback will survive the firmware update without rescue. If the later diagnosis is correct removing the nvme drive won’t help me because success will depend upon how Fedora 35 configured my EFI.
1 Like
If the later diagnosis is correct removing the nvme drive won’t help me because success will depend upon how Fedora 35 configured my EFI.
@patch If you are worried about this, you could always verify what’s on your EFI partition (it should be mounted, otherwise dnf couldn’t rerun grub or systemd-boot), and copy the bootloader to the backup location if it’s not already present. That’d put you in the same position as me, where I used a flash drive to run the update and was able to boot into it. I will say that there’s a suspicious folder \EFI\Insyde on my SSD’s UEFI partition, which is the company that supplied the BIOS/flasher, so that’s not good, but clearly people are able to update without their main drives installed too.
Of course, it’d be best if BIOS updates didn’t wipe the EFI part of NVRAM (I’ve never had a system that wiped this on update), but…
1 Like
Good point.
# tree /boot/efi
/boot/efi
├── EFI
│ ├── BOOT
│ │ ├── BOOTIA32.EFI
│ │ ├── BOOTX64.EFI
│ │ ├── fbia32.efi
│ │ └── fbx64.efi
│ └── fedora
│ ├── BOOTIA32.CSV
│ ├── BOOTX64.CSV
│ ├── gcdia32.efi
│ ├── gcdx64.efi
│ ├── grub.cfg
│ ├── grubia32.efi
│ ├── grubx64.efi
│ ├── mmia32.efi
│ ├── mmx64.efi
│ ├── shim.efi
│ ├── shimia32.efi
│ └── shimx64.efi
Looks like I should have a bootable OS after the update. Weird that the flasher does end up writing to the EFI partition though. I’ll give the update a whirl with my drive removed anyway then.
I’m still a little confused about what is being stored in nvme that is necessary here and how that interacts with the boot process, but I think I need to do more reading on how EFI booting works.
Update: Success.
Ok, so I took out all bootable things (nvme, 1tb expansion) and only had the usb drive in. Then it worked.
It seems the EFI USB stuff is using a hard coded location for something… maybe?
1 Like
Your a gentleman and a scholar good sir! Pleased to see another BSD barbarian round these parts.
1 Like
Which method did you use? I’m seeing one for fwupdmgr and another from USB - trying to decide my action… I’m on Arch Linux and love my setup. I use systemd, and read the more recent posts about that, so…
For me I did install fwupd, ran:
fwupdmgr enable-remote lvfs-testing
fwupdmgr get-updates
but
fwupdmgr update reports no updatable devices…
So I’m currently thinking (1/04/22) that the EFI Shell Update Method that was posted here on 12/23/21 posted by Framework Team and updated to the top of this post is the way to go… making sure I grasp everything - but wanna goto 3.07.
Thanks.
To verify; (I’m on Arch Linux w/ systemd and EFI…) using GRUB. I’m going from 3.02 to 3.07, hopefully.
This EFI shell method is preferred as of 1/5/22?
Not user “drs” workaround?
Thanks for all the data here. I’ve formatted a USB to FAT32 and unzipped Framework_Laptop_BIOS_EFI_3.07.zip to it. I feel like I’m almost knowledgeable to pull the trigger.
I’ve updated our Knowledge Base article and the post here to note that 3.07 is out of Beta for Windows and is fully released for updating. We’re still holding the Beta tag for Linux though, as the LVFS update process isn’t complete and the EFI update process may require reinstalling your bootloader, which is not a great experience.
13 Likes
Makes perfect sense. I didn’t freak out, as I installed Arch more than enough times in my life (guess that’s kinda sad). But seems like some users were chasing the wrong thing, at least initially.
A warning might be appropriate as well, as there are some (like me) who didn’t install a fallback for EFI entries, but @Jake_Bailey pointed out nicely that there is a way to avoid the problem. Always learning, thanks!
Yeah, this makes a lot more sense.
Basically, one of the requirements of UEFI is that the bootloader is “registered” with the firmware. This is especially apparent and annoying on my ancient Asus notebook PC, where I had like 30 duplicate entries in the firmware.
A lot of people responding have alluded to that, so I’ll get to something that I havent’ seen mentioned much.
Some firmware have a “browse” feature. This feature enables users to navigate readable partitions (i.e. FAT32 partitions) to dig up the appropriate boot loader and add them manually, and then select them as a bootable option from the firmware.
Dell’s support forum illustrates how this might look in their implementation: [Link]
In this article, they’re asking about how to get their computer to use the (underutilized) Windows 7 EFI loader on an optical disc, but the same process would apply to internal storage as well; you need to have:
- The ability to add a boot.efi file;
- The ability to browse to it;
- The ability to save that configuration to the EFI nvram/firmware.
Note that I’m not saying that this is a fix for you or anybody, but it’s one potential future solution; any tool that is capable of adding this information to the firmware is useful, and it happens that GRUB can do this, but I think this would be useful functionality for the Framework as well, for cases where a boot device isn’t available.
This would be a good feature to implement. Possibly more important that implementing an Fn lock indicator.
1 Like
I updated with the USB method. It got me onto 3.07 from 3.02, which (judging by another post I saw from you) is the same situation you’re in. I just followed the steps, live-booted to the USB, and waited for it to flash the new BIOS. Word to the wise, though - I had to reinstall my bootloader after. Luckily, it’s not a huge hassle if you’ve got an Arch install medium lying around like I do, but do be prepared for it.
I have a dual boot with Ubuntu 20.04 and Windows 10, and after updating my bios to 3.07 my computer no longer showed grub when booting (just booted straight to windows). I fixed it by changing the “EFI Boot Order” under Boot in the “UEFI Firmware settings”. I set “New Boot Device Priority” to First and placed my ubuntu drive before windows.
This doesn’t sound like other solutions I’m seeing from others with dual boot or just Linux installs. Is this something I’m not supposed to do, was I lucky, or is there some difference due to me using a debain based distro instead of Arch?
Is there any reason these get posted to the forum rather than a specific Bios & Drivers section under “support” like most motherboard manufacturers?
They could have both. I just want to be able to check for updated bios or drivers quickly.
For instance, I have to search the forum, or the Knowledge base to even find the bios and drivers.
It would be really helpful and convenient if hovering over support had a fourth option.
Knowledge Base
Setup, Upgrade and Repair Guides
Contact Support
Bios and Drivers
2 Likes
(This started as a post asking how long the process was supposed to take. Before I clicked the “⮪ Reply” button, though, I checked on the laptop and the screen had changed.)
For anybody else freaked out as I was by how long the Windows-based BIOS updater sat spinning on “Getting Windows ready / Don’t turn off your computer”, it took at least 5min for me and maybe as much as 10min. Then it eventually rebooted to a colored-text-on-black-background screen with a progress bar and a percentage complete.
I did have to update most of the settings in the BIOS afterwards, including boot order (to prevent the system booting directly into Windows — I’ve got a Windows UEFI partition and a separate Ubuntu UEFI partition), but once I did that my existing GRUB configuration was fine. (Secure Boot did not get re-enabled automatically, though.)
Somewhat obnoxiously, on the first boot after the BIOS upgrade, Windows again tried to market all Microsoft’s online services at me and get me to stop using Firefox, but it wasn’t very many clicks to tell it where it could go.
This is a dual-boot system that I usually boot into Linux (with two EFI partitions, one used for Windows and one for Linux), but I figured it was safer (and less work since I might need to reinstall Grub) to use the regular Windows installer. I kind of suspect the UEFI BIOS updater might have made the whole process quicker.
This sounds like Windows installed some updates while you were firing off the firmware update. Usually it brings those offers up when it’s installed/upgraded to a new build.
In other words, that’s a Windows issue, not a firmware issue 
Yeah, I just wanted to give people a heads-up to expect that. (I’m not a frequent Windows user myself so it was a surprise to me.)
1 Like
We follow the following release process:
Internal Engineering validation → Internal dogfooding → Forum Post (beta)-> Knowledgebase (stable).
Once a release ends up on the Knowledgebase we consider it stable.
Since this was the first time we have emailed users to push them to update their bios, we had a lot of users update who do not use the forum and discovered this new issue; that some users have boot options saved in NVRAM, and this is cleared on update.
Right now the clear process is done by the previous bios version during the update process, so while updating from 3.07 the NVRAM will also be cleared.
I do want to apologize for this. I would also be frustrated if my system did not boot properly after a bios update. We are adding this requirement and tests to any future bios updates we release, and future products.
11 Likes
Ah, makes sense. I guess updating on shutdown is marginally more sensible than updating on boot when you might be in a hurry to use the machine.
Does this mean the 3.07 removes the “clear NVRAM” code & future updates should be smoother sailing? Or will that be fix be included in a future update?