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.
1 Like
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.
1 Like
Does this driver pack fix the Windows 11 issue with Intel SST driver or will an updated driver pack be issued by Framework?
Windows 11 Upgrades Blocked by Intel SST Audio Driver | Tom’s Hardware (tomshardware.com)
2 Likes
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.
3 Likes
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.
11 Likes
@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
Kieran,
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.
Tks
Nick
1 Like
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)
2 Likes
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:
fwupdmgr get-updates - Update
fwupdmgr update
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!
6 Likes
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.
4 Likes
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?
Installed under Fedora 35 KDE, ran fwupdmgr non root as well and it worked fine for me. Maybe root causes issues?
1 Like
Tried again, following the non-root fwupdmgr get-updates then fwupdmgr update route. Answered yes to the reboot prompt there, but nothing happened on reboot.
The whole process was running with AC connected and Secure Boot disabled (tried with enabled too, no change).
Still no luck getting the update to happen.
@Benjamin_Bridges since you’re on F35, presumably you also have the 15.4-5 version of shim* installed (dnf list installed shim*). I have 15.4-5 and I don’t see anything in updates-testing for this package.
I wonder if other configuration changes play a role here. Are you on an encrypted root FS? (shouldn’t matter since /boot and /boot/efi are not on root/encrypted, but I can’t think what else could be different here)
These are the two FW upgrade files I can think of that correspond to “staged” upgrades that aren’t being actioned on boot:
-rwx------. 1 root root 76418 Dec 5 12:42 /boot/efi/EFI/fedora/fw/fwupd-3b8c8162-188c-46a4-aec9-be43f1d65697.cap
-rwx------. 1 root root 35699096 Dec 5 12:42 /boot/efi/EFI/UpdateCapsule/fwupd-b3bdb2e4-c5cb-5c1b-bdc3-e6fc132462ff.cap
Any idea how to proceed/diagnose here is welcome.
1 Like
@Kieran_Levin Thanks a bunch. I was able to get it, and it seems to work fine. I was waiting for the mouse-after-suspend patch on fedora descendants, so hopefully it works.
@dimitris I just checked, looks like I was wrong. Everything seemed like it worked but I just checked and no dice. Everything looks fine but on reboot no update. My bad.
@Benjamin_Bridges thanks. Pattern seems to be Fedora-specific - AFAICT everyone who has successfully updated using LVFS has been on non-Fedora distros.
I’ll try to keep the follow-ups in the Fedora-specific thread then, to reduce noise in this one. There’s a reference there to a shim github issue that seems related, and whose fix appears to be addressed/merged in e.g. Ubuntu but only in the main branch and an as-yet unreleased release branch in Fedora.
1 Like
I was informed before that BIOS 3.06 would fix the issue with increased voltage coming across the bottom left and top right expansion card ports, causing a safety shut off until reboot. I have installed 3.06 and this is still an issue. Is a fix being worked on?
Context: here is the original post where it is discussed that 3.06 fixed a high inrush current issue on the aforementioned ports.
1 Like