I was never able to resolve this. I rewrote my Windows 10 install onto Ventoy, copying it over from a VM. I documented this:
Works fine this way.
I tried again, this time booting from an actual Windows installer and using Shift+F10 to get a command prompt window. I then ran the install from a separate flash drive. Unfortunately I still ran into this problem. Is there a BIOS setting I need to change in order for this installation to be possible?
I toggled Secure Boot to no effect. Maybe it has something to do with the presence/absense of the Windows boot loader but I’m not sure how its presence can be detected from within the OS.
The message seems to allude to UEFI capsule updates not allowed. Some BIOSes have a setting for this. Framework’s does not.
You seem to be on Linux. Sit tight, LVFS updates are coming soon.
1 Like
How large is your EFI partition? Do you know how much is available?
1 Like
I’m not sure. I booted from an official Windows 10 installation flash drive. I don’t know how it’s partitioned.
One thing of possible interest, both times I tried this I had physically removed my OS SSD from the computer due to reports of this method messing with the Grub config. I wonder if there is any way that could have something to do with it.
Try this:
From the Windows boot media, his Shift+F10 to bring up the command prompt. Then do the following:
Microsoft Windows [Version 10.0.22000.376]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Meep>diskpart
Microsoft DiskPart version 10.0.22000.1
Copyright (C) Microsoft Corporation.
On computer: JENNY-XJ9
DISKPART> lis dis
Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 931 GB 438 GB *
Disk 1 Online 59 GB 15 MB
The first drive (which is the biggest) is usually the drive we want to select. Sel is the short-form for Select
DISKPART> sel dis 0
Disk 0 is now the selected disk.
DISKPART> lis par
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 195 MB 1024 KB
Partition 2 Recovery 886 MB 196 MB
Partition 3 Primary 492 GB 1084 MB
DISKPART> sel par 1
Partition 1 is now the selected partition.
DISKPART> assign
Technically we only need the first three letters, but the first three characters in assign might get this filtered.
DiskPart successfully assigned the drive letter or mount point.
DISKPART> lis vol
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 C Windows NTFS Partition 492 GB Healthy Boot
* Volume 1 E SYSTEM FAT32 Partition 195 MB Healthy System
Volume 2 Clone NTFS Partition 886 MB Healthy Hidden
Volume 3 D NTFS Removable 59 GB Healthy
DISKPART> exit
Leaving DiskPart...
Now that we’ve assigned the EFI system partition a drive letter, we can access the drive as though it were any other drive, except we need to be an administrator.
C:\Users\Meep>e:
E:\>dir
Volume in drive E is SYSTEM
Volume Serial Number is BOBA-FE44
Directory of E:\
11/27/2015 12:57 PM <DIR> !efi
09/17/2019 03:18 PM <DIR> $WINDOWS.~SY
12/21/2021 10:06 PM <DIR> EFI
0 File(s) 0 bytes
3 Dir(s) 169,877,504 bytes free
The final line with the Bytes Free indicates how much space the EFI partition has available. In my experience, the firmware requires about 30MB to update successfully. Windows typically makes the partition about 300 MB.
You can now restart the system. If you’re running this on a fully booted, installed Windows instalaltion, then you’ll probably want to tidy up and unassign the drive letter:
E:\>c:
C:\Users\Meep>diskpart
Microsoft DiskPart version 10.0.22000.1
Copyright (C) Microsoft Corporation.
On computer: JENNY-XJ9
DISKPART> lis vol
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 C Windows NTFS Partition 492 GB Healthy Boot
Volume 1 E SYSTEM FAT32 Partition 195 MB Healthy System
Volume 2 Clone NTFS Partition 886 MB Healthy Hidden
Volume 3 D NTFS Removable 59 GB Healthy
DISKPART> sel vol 1
Volume 1 is the selected volume.
DISKPART> remove
DiskPart successfully removed the drive letter or mount point.
DISKPART>
…And you may exit.
Or, in Debian, y’all can just run df and see what it returns.
Thank you very much for the detailed steps. From my Ubuntu partition it appears that my EFI partition is 500MB.
/dev/nvme0n1p1 497M 229M 269M 47% /boot/efi
However, I want to point out again that I have removed this hard drive when running the bios update from the live disk to ensure that it does not mess with my grub config. Is having too OS drive installed required for this process to succeed? Is there a way around that if so?
I had this happen too. I ended up unplugging my USB-C expansion card and then plugging it back in. This at least seems to have changed the light to a constant red/orange instead of a blinking one.
I’ve also had visual/graphics issues with this driver bundle. Sometimes my mouse will “tear” as I move it across the screen, especially when it travels between the Windows taskbar and the desktop. When this happens, I’ve found that it occurs with both my bluetooth mouse and the touchpad (switching between the two doesn’t solve the problem). Restarting the machine seems to resolve the issue, but I’d definitely prefer it not happen in the first place. 
So far so good on 3.07 and Windows 11, though I have some gripes with the operating system vs W10. Had an issue with the four-finger scroll not being as accurate as before but that seems to have been resolved overnight.
I just noticed this with mine.
My firmware is configured to limit to 85% and my battery is at 86% (“Plugged in”). My best guess is that the firmware is limiting as it should, but the behavior is tripping some kind of threshold indicator or something.
Removing and reattaching the USBC port it was charging from resulted in a steady orange instead of blinky orange.
@Daniel_Schulte @SodaStream Are you sure this behavior isn’t because unplugging your USB-C card results in a tiny bit of battery discharge? From what I can tell, the behavior is:
Charging: Steady orange
Reached threshold (not charging): Blinking orange (1s period)
1 Like
Leans over; observes steady orange 22 minutes later
I’m pretty sure. Three seconds of discharge shouldn’t require 22 minutes (and counting) to trip into blink mode. Right now, Windows is reporting 86% and the light is steady.
I’m not even saying that it’s a horrible thing to happen, but that it can be distracting to slightly worrying when that kind of thing happens without knowing or understanding why. If there is a way to program a tolerance (say, within two percent of the configured threshold) that would result in a steady white, that would resolve some of the worry.
On the other hand, if it’s supposed to blink by now and it’s not, I’d wonder if anything else that relies on the battery threshold is triggering properly.
Oh weird. From what I can tell, mine stays blinking indefinitely. I have the threshold set to 79 and Windows reports it stopping charge at 80%.
The reason I believe this to be intentional is that the blinking is exactly 1 sec on, 1 sec off. Could be wrong though.
@D.H: you’ll probably be interested in this- The Framework Laptop's Embedded Controller (EC) :: HowettNET
@SodaStream I’ve discovered some limited key remapping, but not much else: The Framework Laptop's Embedded Controller (EC) :: HowettNET (this links directly to the key mapping section, even if the title doesn’t suggest that)
3 Likes
Try this:
From the Windows boot media, his Shift+F10 to bring up the command prompt. Then do the following:
…
Even this (SodaStream’s comment #47) didn’t work. I have a Windows To Go (“WTG”) bootable USB with Windows 10 on it. I resized its UEFI partition to 240 megabytes. That didn’t work. Later comments made me realize that the issue might be with the primary disk’s UEFI partition. So I then followed SodaStream’s instructions while within the WTG environment and that didn’t work either. My main drive’s UEFI partition is 512M in size and is almost entirely free.
Now, I know that the installer is attempting to do something with that partition because after it gives the usual “your BIOS doesn’t support secure flash” error, the letter assignment is removed (and the drive is no longer accessible through that letter until I assign it again). The partition stops showing up in the list of available mapped drives.
I have tried everything short of buying a new NVME disk just for the purpose of installing Windows onto it so that I can update the BIOS. It simply should not be necessary to go to such lengths just to update the BIOS.
What in the world is going on here??? I’m pulling my hair out over this.
I’m using Ubuntu Unity (https://ubuntuunity.org) version 21.04. My NVME SSD is 1 TB in size.
I fully expect the standard Ubuntu installer will create its UEFI partition in the same way that Ubuntu Unity did, so I shouldn’t be unique here in this. My system is a batch 6 system that came with BIOS 3.06.
An overview for those unsure of how to install the beta when on Linux (using Hiren Win10 USB Live Boot):
*NOTE: Try this at your own risk. Just because it worked for some doesn’t mean it will work flawlessly for you.
Using a Windows computer (haven’t tested it on Linux with .exe):
- Download Hiren iso
- Download Hiren USB Flasher (ISO2USB)
- Download 3.07 Bios File (Note: It’s a beta!)
- Have a flash drive ready (I used an 8GB one).
- Open Hiren’s USB Flasher from step 2. It should auto-select your USB.
- Select the Hiren ISO file in the USB flasher menu.
- Flash the ISO!
- Once done flashing, open the USB via “This PC” in your file explorer.
- Drag the 3.07 beta bios file into the now flashed usb
- Shutdown your Framework Laptop and boot into your flashed Hiren USB.
- Once it loads up and you are presented with a “Windows 10” desktop, open up “This PC”
- Click on the main drive (where your Hiren files live) and you’ll see the BIOS file you dragged there earlier.
- Double click to install and your BIOS update process will take place automatically.
- Once complete, your Framework Laptop will boot back into Linux.
- To confirm, either:
a) Shutdown your Framework Laptop and boot into BIOS
b) runsudo dmidecode | lessin your terminal to confirm new BIOS version (3.07)
2 Likes
So when charging has hit the set amount will the led next to where it is plugged in begin to blink? Is this normal behavior?
I believe so, that is certainly what is happening to me when I set it to 80% charge and it reaches it
1 Like
The 0.0.3.6 on LVFS testing is the prior beta version, the 3.06 one.
1 Like
For the Linux/BSD/etc users. I have updated the first post to include a link to an EFI based updater that you can run from a thumb drive.
I am seeing an issue where the update fails in Fedora 35 from LVFS.
Sorry for the delay getting the LVFS version out. In the future I will publish EFI shell updates for new updates moving forward.
25 Likes