@Richard_Tango-Lowy I’d argue that most people who use linux on a framework have bought the DIY edition and don’t mind hacking around a bit to make things work. Since most of them probably also had to install the wifi card themselves, i’d say they are quite patient as well. That being said, a (near) simultaneous push to lvfs-testing would be nice, I agree.
While I enjoyed assembling my laptop, it only took about 15 minutes. I run a business and use my computer for real work. Keeping it functioning normally (e.g., not breaking the battery) isn’t something I should need to deal with downloading another OS for. That’s why the linux community has fwupdate.
Not beating on the Framework folks here. Just pointing out that BIOS support is rather fundamental–it’s not like whether or not the fingerprint reader works.
So I installed the driver bundle and the new BIOS today. Both appear to be working great so far, only two things:
-
It also wrecked GRUB for me, I couldn’t boot Gentoo after updating the firmware. Fortunately, the fix was super easy - all I had to do was grab a USB, mount my installation, and rerun
grub-install
andgrub-mkconfig
, and everything works perfectly again. For any other Linux users considering the update, just make sure you have access to a recovery medium when you update, or else you could potentially find yourself stranded. -
The light on the left side of the Framework changed in behavior. It used to be a steady white while the laptop was on, now it blinks red, on and off. I haven’t actually noticed any problems so far, but I thought it was worth mentioning anyway.
Install went fine for me, however whenever my bios gets updated it sets the boot order (in the bios) to auto, which always sets Windows to boot. I have to set the boot order to First or Last and then change the primary to be Linux so I can boot Linux or Windows via GRUB.
We are in the process of publishing this through LVFS as well. We are doing some validation on the embargo channel and will release an update to the testing channel soon. We want to get this out as soon as possible.
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.
How large is your EFI partition? Do you know how much is available?
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)
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)
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.