You’ll have to submit that feature as a request in a future BIOS.
Thank you. How do I make a request? Do you know?
black tape or better for astronomy, layers of red tape.
Red KB lighting would be great.
Do we know if there will be options to change the way that the light works in future bios updates?
I just so happened I was working on getting boot times down as low as possible, and I thought I hit the limit. So my anecdote is going from 20 seconds cold boot to 15 seconds, and from 19 seconds resume from hibernate to under 13 seconds, reliably .
I have an update on LVFS in the embargo channel, and just need permission to move it to testing, so once I get it on the testing channel the community can try it out.
Thanks, it was a space issue in my EFI partition. I deleted some old vendor directories and it was able to apply the 3.06 update.
I had a similar issue with 3.03. I ended up resizing my EFI partition because it was only like 30MB (probably due to an issue with the imaging tool/methods I used… or else I missed a tick box somewhere. Whoops!).
I think it’s advisable to not go any smaller than 128MB; 300MB is Microsoft’s standard size. You’re not going to miss the space.
Does this driver pack fix the Windows 11 issue with Intel SST driver or will an updated driver pack be issued by Framework?
I use ~512MB on all of my devices, there really isn’t any reason to skimp on this since it’s really never going to be a giant amount of space compared to how much capacity HDDs and SSDs have nowadays.
@Kieran_Levin Any update on LVFS? Or when you expect to make progress on it?
Bios 3.06 is currently in the LVFS testing channel.
I did see a failure in Manjaro Linux on the channel which we need to look at.
@Kieran_Levin is it still on LVFS testing? I still only see the dbx update when I enable it; am I doing something wrong?
[d@greebo ~]$ fwupdmgr enable-remote lvfs-testing ╔══════════════════════════════════════════════════════════════════════════════╗ ║ Enable new remote? ║ ╠══════════════════════════════════════════════════════════════════════════════╣ ║ The LVFS is a free service that operates as an independent legal entity and ║ ║ has no connection with Fedora Linux. Your distributor may not have verified ║ ║ any of the firmware updates for compatibility with your system or connected ║ ║ devices. All firmware is provided only by the original equipment ║ ║ manufacturer. ║ ║ ║ ║ This remote contains firmware which is not embargoed, but is still being ║ ║ tested by the hardware vendor. You should ensure you have a way to manually ║ ║ downgrade the firmware if the firmware update fails. ║ ║ ║ ║ Enabling this functionality is done at your own risk, which means you have ║ ║ to contact your original equipment manufacturer regarding any problems ║ ║ caused by these updates. Only problems with the update process itself ║ ║ should be filed at https://bugzilla.redhat.com/. ║ ╚══════════════════════════════════════════════════════════════════════════════╝ Agree and enable the remote? [Y|n]: Authenticating… [- ] Authenticating… [***************************************] Do you want to refresh this remote now? (Requires internet connection) [Y|n]: Downloading… [***************************************] Downloading… [***************************************] Successfully enabled and refreshed remote [d@greebo ~]$ fwupdmgr get-updates Laptop │ └─UEFI dbx: │ Device ID: 362301da643102b9f38477387e2193e57abaa590 │ Summary: UEFI revocation database │ Current version: 33 │ Minimum Version: 33 │ Vendor: UEFI:Linux Foundation │ Install Duration: 1 second │ GUIDs: c6682ade-b5ec-57c4-b687-676351208742 │ f8ba2887-9411-5c36-9cee-88995bb39731 │ 59145971-a32d-5465-9497-cfb56b4704be │ c9f47f69-d72a-55b7-b19c-a261a4b0ca53 │ Device Flags: • Internal device │ • Updatable │ • Supported on remote server │ • Needs a reboot after installation │ • Only version upgrades are allowed │ └─Secure Boot dbx: New version: 77 Remote ID: lvfs-testing Release ID: 6101 Summary: UEFI Secure Boot Forbidden Signature Database Variant: x64 License: Proprietary Size: 7.1 kB Created: 2016-08-09 Urgency: High Vendor: Linux Foundation Duration: 1 second Flags: is-upgrade Description: This updates the dbx to the latest release from Microsoft.
Edit: For completeness:
[d@greebo ~]$ fwupdmgr get-remotes Laptop │ ├─Linux Vendor Firmware Service (testing): │ Remote ID: lvfs-testing │ Type: download │ Keyring: jcat │ Enabled: true │ Checksum: a62eadf7695edb4e5ae4450bac2e9f52a2d28761e062cd1b3415ecf1905c499b │ Age: 5.32m │ Priority: 1 │ Filename: /var/lib/fwupd/metadata/lvfs-testing/metadata.xml.gz │ Filename Signature: /var/lib/fwupd/metadata/lvfs-testing/metadata.xml.gz.jcat │ Filename Source: /etc/fwupd/remotes.d/lvfs-testing.conf │ Metadata URI: https://cdn.fwupd.org/downloads/firmware-testing.xml.gz │ Metadata Signature: https://cdn.fwupd.org/downloads/firmware-testing.xml.gz.jcat │ Report URI: https://fwupd.org/lvfs/firmware/report │ Automatic Reporting:false
Have 3.0 BIOS, wonder if you could expand on the size needed in the boot partition for the capsule update file. Am waiting for the official 3.06, not beta, so no hurry here.
Just popping in to say I enabled the testing remote and installed the new bios and everything seems to be working fine.
Tested on elementary OS 6.0 (based on Ubuntu 20.04)
EDIT: Seems like people run into trouble. Run these commands as non-root. You’ll get password prompts when needed.
Installed successfully on Pop!_OS 20.04.
- Switch to lvfs testing:
fwupdmgr enable-remote lvfs-testing
- Update firmware repo:
You can also install from GNOME settings in “Firmware” after enabling testing repo.
Framework will reboot and install the BIOS, spin the fans VERY loud for a few minutes.
After restart all works OK. Fingerprint reader, sound, Fn keys, etc. Cheers!
I’ve been following that exact procedure on Arch and it won’t identify the update…it always tells me that there is nothing to update.
I’m sure I’m doing something wrong, but if I can provide any more information about what the problem is, let me know!
Confirmed the update works using the steps from Gio_Mag. I’m on Ubuntu 21.04. The system rebooted and the firmware update took quite a bit longer than I expected (several minutes) but did eventually complete successfully. The progress bar does not seem to move at a regular pace; it started out at around 40% and then quickly went to ~99% and then just sat there at “nearly done” for several minutes before it finally completed and rebooted. Not the best experience, but I’m just happy it worked at all!
Having the Framework firmware updates integrated into the Linux ecosystem like this is a huge deal. Thank you to the Framework team for making the effort.
Attempting to upgrade to 3.06 on Fedora Linux 35 via LVFS and I’m getting the exact same issue as @dimitris is describing here: https://community.frame.work/t/bios-3-06-on-lvfs-testing-but-error-trying-to-update-under-fedora-35/ I don’t have anything else to add, except to make sure that @Kieran_Levin saw this, as I didn’t see you active in the other thread.
@gjason, not sure but I’m running fwupdmgr without sudo… it’s asking for authorization AFTER you run get-updates and update…
Or try GNOME gui after get-update. What does it show?