same issue, my BIOS password no longer works, I was running BIOS 3.03.
I cannot even start booting since my machine requires a password to boot.
I’m trying to update from 3.03 to 3.05b, but it doesn’t show me any updates since the version number of the current BIOS is showing up as 771. Refreshing the metadata doesn’t solve this unfortunately ( sudo fwupdmgr refresh --force).
fwupdmgr get-devices 1e4fa9cea0b89e613370cf9657ffa0b6d3f37fec
Framework Laptop 13 (AMD Ryzen 7040Series)
│
└─System Firmware:
Device ID: 1e4fa9cea0b89e613370cf9657ffa0b6d3f37fec
Summary: UEFI System Resource Table device (Updated via caspule-on-disk)
Current version: 771
Minimum Version: 1
Vendor: Framework (DMI:INSYDE Corp.)
Update State: Success
Problems: • Device requires AC power to be connected
GUID: b5f7dcc1-568c-50f8-a4dd-e39d1f93fda1
Device Flags: • Internal device
• System requires external power source
• Needs a reboot after installation
• Cryptographic hash verification is available
• Device is usable for the duration of the update
• Updatable
Device Requests: • Message
Any ideas how to solve this? I have lvfs-testing enabled.
Rebooting fixed it for me. Also make sure you’re plugged into AC or it won’t offer to do the upgrade.
1 Like
Rebooting doesn’t do it for me and I’m also connected to AC. I’ve already tried a number of times of the past few days. My workflow:
fwupdmgr refresh --forcefwupdmgr get-devicesfwupdmgr get-updatesfwupdmgr update
Just gives me:
$fwupdmgr update
Devices with no available firmware updates:
• Fingerprint Sensor
• System Firmware
• UEFI dbx
• WD BLACK SN770 1TB
No updatable devices
and
DeviceId: 1e4fa9cea0b89e613370cf9657ffa0b6d3f37fec
Name: System Firmware
Guid: b5f7dcc1-568c-50f8-a4dd-e39d1f93fda1
Summary: UEFI System Resource Table device (Updated via caspule-on-disk)
Plugin: uefi_capsule
Protocol: org.uefi.capsule
Flags: internal|updatable|require-ac|registered|needs-reboot|can-verify|usable-during-update
RequestFlags: allow-generic-message
Checksum: SHA256(29158964649ac1f4bdaf8ed36b857cb174af99229a648f5bc5e412105848e9c0)
Vendor: Framework
VendorId: DMI:INSYDE Corp.
Version: 771
VersionLowest: 1
VersionFormat: number
VersionRaw: 0x00000303
VersionLowestRaw: 0x00000001
Icon: computer
Created: 2024-04-09
UpdateState: success
Does fwupdmgr get-remotes show lvfs-testing as enabled?
tldr: yes
$ fwupdmgr get-remotes
Framework Laptop 13 (AMD Ryzen 7040Series)
│
├─Vendor (Automatic):
│ Remote ID: vendor-directory
│ Type: directory
│ Keyring: none
│ Enabled: true
│ Priority: 1000
│ Filename: /usr/share/fwupd/remotes.d/vendor/firmware
│ Filename Source: /etc/fwupd/remotes.d/vendor-directory.conf
│
├─Linux Vendor Firmware Service (testing):
│ Remote ID: lvfs-testing
│ Type: download
│ Keyring: jcat
│ Enabled: true
│ P2P Metadata: true
│ P2P Firmware: false
│ Checksum: 77c4ae2f2efbace0c1d2e4c772ae2fb6231acf1ef3ec8ff4bb57bdcd753cd477
│ Age: 2 hours
│ Refresh Interval: 24 hours
│ Priority: 1
│ Filename: /var/lib/fwupd/metadata/lvfs-testing/metadata.xml.zst
│ Filename Signature: /var/lib/fwupd/metadata/lvfs-testing/metadata.xml.zst.jcat
│ Filename Source: /etc/fwupd/remotes.d/lvfs-testing.conf
│ Metadata URI: https://cdn.fwupd.org/downloads/firmware-testing.xml.zst
│ Metadata Signature: https://cdn.fwupd.org/downloads/firmware-testing.xml.zst.jcat
│ Report URI: https://fwupd.org/lvfs/firmware/report
│ Automatic Reporting:false
│
└─Linux Vendor Firmware Service:
Remote ID: lvfs
Type: download
Keyring: jcat
Enabled: true
P2P Metadata: true
P2P Firmware: false
Checksum: 236382e0224a5a271aca9378ddbed1765ec679ae29ba62654be8f409fc8f1336
Age: 2 hours
Refresh Interval: 24 hours
Filename: /var/lib/fwupd/metadata/lvfs/metadata.xml.zst
Filename Signature: /var/lib/fwupd/metadata/lvfs/metadata.xml.zst.jcat
Filename Source: /etc/fwupd/remotes.d/lvfs.conf
Metadata URI: https://cdn.fwupd.org/downloads/firmware.xml.zst
Metadata Signature: https://cdn.fwupd.org/downloads/firmware.xml.zst.jcat
Report URI: https://fwupd.org/lvfs/firmware/report
Automatic Reporting:false
That’s very odd then; Can you please bring a bug report to GitHub - fwupd/fwupd: A system daemon to allow session software to update firmware and we can dig in further?
Attach the output of sudo fwupdtool update -vv to the bug report.
Thanks for looking into it, Mario! For anyone else encountering this issue, track progress here: No testing BIOS update available for Framework 13 · Issue #7060 · fwupd/fwupd · GitHub
4 Likes
For those following along it’s a regression in libxmlb 0.3.17 (specifically) Downgrading to 0.3.16 if it’s available will fix it, and 0.3.18 will be released this week with the fix.
7 Likes
I was having the same issue on Debian testing.
Applying this patch mentioned in the discussion that you linked on top of libxmlb 0.3.17 does fix the issue and I could update the BIOS to 3.05 !
1 Like
I upgraded from 3.03b. I haven’t tried rolling back yet, as others suggested, nor tried the full bios defaults reset. Pretty busy atm, I’m on the last two weeks of the college semester. I’ll check back when I can get to it.
I removed the sg_display=0 parameter and switched to iGPU “auto” mode, and was not able to replicate the GPU reset issues I was having before in a couple places where I could consistently trigger it. I also tried an older kernel with an older initrd and couldn’t trigger it there either. However, it was already an intermittent issue, so I’ll have to keep testing things. If I don’t see it after multiple attempts to replicate, I might have to update my bug report in Debian.
Also tried running with sg on and igpu auto, finished multiple runs of the built in cyberpunk benchmark without any of the artifacting I had previously and no issues running a long ai only game of stellaris (I just had the computer play itself as a stress test XD).
So far so good, I’ll leave it like that and will update if issues show up.
I’m very glad to report that the BIOS update fixes the white display artifacts issues for me !
I had a pretty reliable way of triggering it on Debian testing with Plasma which was :
- boot
- login with a first user
- switch to a second user session
And now with 3.05 I cannot reproduce the issue anymore after several tries.
Yay ! \o/
(that’s all without sg_display=0)
1 Like
Given the actual feedback around BIOS 3.05 will there be an official release soon or there are still issues that may need to be investigated for this BIOS release ?
2 Likes
Wondering the same.
@Kieran_Levin Anything to note about this AMD Chipset Driver?
It isn’t a version available for download from AMD. The modification date of the AMD_Chipset_Drivers.exe from inside the AMD_Chipset_Software_5.06.29.310.exe has a modification date of 2023-06-29.
It is quite an old and outdated chipset driver compared to what is available from AMD. The latest release from AMD is 6.02.07.2300 with a release date of 2024-03-13 and a modification date of 2024-02-08. So 8 months newer and 2 official releases since the driver included in this bundle.
3 Likes
Do those drivers need to be adjusted for framework or why wouldn’t they pull the latest? I’m a bit confused now…
Another issue I encountered with this firmware is that /sys/class/thermal/thermal_zone3/temp occasionally shows a value of 180 °C.
It is a unified driver for multiple platforms across multiple generations.
So it would be possible* that there are no changes that are relevant to the FW platform after that version.
*: possible. Probable though? Given FW not updating other drivers that do affect existing platforms much and based on the way other OEMs do it: more likely they were tracking a specific bug, and the version they are shipping now is the one that has that fixed. But ignoring other benefits of newer drivers as that would not fix issues that the manufacturers was “tracking” but would require more testing.
1 Like