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.
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:
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.
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
(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.)
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.
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?
@nrp and update on when 3.07 will be available on LVFS? I have not been able to successfully upgrade with the EFI USB installation method, so I’m eagerly awaiting this release. Thanks.
I got my BIOS updated to 3.07, using the USB EFI Shell method and using an arch-linux live install USB to run grub-install and grub-mkconfig - mine was a bit nervewracking because I use a LUKS encrypted drive, but it just took an hour or so making sure I had the filesystem recreated correctly. HECK, I don’t even know if I had to mount the encrypted /home volume but… it all worked out fine.
I did post my commands on the Arch BIOS Update Guide post; and send thanks to @Daniel_Boling for helping to paint a perfect picture of what needed to be rebuilt. I’m glad I finally played w/ GRUB more…
[If you don’t have the DEDSEC GRUB themes, yer missing out!!!]
DEDSEC Grub2 Link
pAULIE42o
. . . . . . . . .
/s
It’s been almost a month now on BIOS 3.07 and it’s working great. The battery charge level limit works exactly as expected. And I really really like the new “power on when external power attached” option. It means I can take my closed, powered-off laptop, plug it into my Thunderbolt docking station, and the laptop powers on automatically without me having to fiddle around with opening and closing the lid to hit the power button.
Loving the new battery-charge limits! I no longer feel “scared” when leaving my system charging overnight, whereas before I was trying to “limit” it’s charging manually as to preserve the battery. Yes, I know I could just buy a new one in the year or two that I would start having issues, but I wanted to preserve it as long as possible and figured this feature was coming along.
Next thing I’m wondering about - I would like to request a “Wake on USB” feature like destops (and most of my previous laptops) have, as opposed to having to press the power-button to power on. There’s already a wake on AC adapter, which I was a little confused on the use-case. I know there is a better place to recommend this feature, I just have to find that thread again…
Does the 3.07 BIOS reset any settings that I might have forgot to change back?
I’m noticing some weird screen tearing(?)/glitching when I hit my mouse on the left side of the screen. The window kinda bounces to the right an inch, in a weird glitchy way… AND, firefox or discord will just shutdown at times! Weird…
I’m liking the battery setting - my Frame is sitting at 60% always, as I stay on A/C. Any thoughts about these two new issues after upgrading BIOS to 3.07? Arch Linux, GNOME, framework on 3.07…
Wake on AC is wonderful when you regularly use a laptop on a Thunderbolt dock in a desk setup where it’s not necessary to have the laptop screen (saves having to faff around opening it just to turn it on and close it again).
On the flip side, it’s ruddy annoying when you just want to plug it in to charge!
Same as ‘wake on lid open’ - fantastic when you want to start using the machine, ruddy annoying when you can’t remember if you put it into hibernation/shutdown and just want to check!
What’s even more annoying though is when your IT admin turns both on and then locks the BIOS so you can’t turn them off 