Looks like they’ve gotten some progress, maybe: FW Desktop 3.04 slow grub/linux boot · Issue #138 · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub
The communication can probably use some improvement.
Looks like they’ve gotten some progress, maybe: FW Desktop 3.04 slow grub/linux boot · Issue #138 · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub
The communication can probably use some improvement.
For now, I think the following blocks the 0.3.4 update so you don’t accidentally upgrade to it:
fwupdmgr block-firmware a20024b975a82a6d8166c161d6fdfa9859fe6d47542932816c1bb6e3f4ccf3be
Came here from Reddit, I installed both the latest drivers and BIOS, and ended up with the same slow boot issue others reported. Initially not sure which of the 2 was the issue, but was pretty sure it’s one of them…
Also since the latest driver and BIOS updates, I realized my FW will not return properly from Hibernation. It always loads like it was shut down. Did anyone else experience this issue? I feel like this is yet another driver issue somewhere…
I also opened a case with support for the slow boot issue, they asked me to go back to BIOS 3.03. And indeed the boot time went back to around 20 seconds from like a minute (or sometimes even more).
I hope one day someone from the Framework team will comment, but until then, we’re just shouting into the noise, being ignored.
Looks like they found the cause of the issue with the long boot time.
You can also verify before running the above command by running:
$ fwupdmgr search a20024b975a82a6d8166c161d6fdfa9859fe6d47542932816c1bb6e3f4ccf3be
Framework Desktop (AMD Ryzen AI Max 300 Series)
│
└─Desktop Ryzen AI MAX 300 System Update:
New version: 0.0.3.4
Remote ID: lvfs
Release ID: 132193
Summary: Framework Desktop System Firmware for Ryzen AI MAX 300 Mainboards
License: Proprietary
Size: 36.1 MB
Created: 2025-11-19 00:00:00
Urgency: High
Tested: 2025-11-22 00:00:00
Distribution: bazzite 43 (bazzite-deck-gnome)
Old version: 0.0.3.3
Version[fwupd]: 2.0.16
Tested: 2025-11-20 00:00:00
Distribution: bazzite 42 (bazzite-gnome)
Old version: 0.0.3.3
Version[fwupd]: 2.0.12
Tested: 2025-11-20 00:00:00
Distribution: fedora 41 (workstation)
Old version: 0.0.3.3
Version[fwupd]: 1.9.30
SBOM: /lvfs/devices/component/132193/sbom
Vendor: Framework
Duration: 2 minutes
Description:
This BIOS release contains the following changes:
• Updated the AMD PI code to version 1.0.0.2.
• Added support for 3A charging profiles on USB-C ports, enabled only when the BIOS setting "Force power supply on in standby" is set to "Enabled."
• Fixed an issue where the system incorrectly showed an "invalid supervisor password" error when the user set the TPM to Hidden and set the supervisor password in the same BIOS session.
• Fixed an issue where the storage password could not be removed after being set in the BIOS.
• Resolved a bug preventing the specific keyboard from functioning while in the BIOS interface.
• Improved the PXE Boot behavior, ensuring the system automatically attempts the next boot device upon a network boot failure.
• Enhanced the Power On AC behavior, allowing the feature to work correctly without requiring the system to boot into the Operating System at least once for initialization.
Checksum: a20024b975a82a6d8166c161d6fdfa9859fe6d47542932816c1bb6e3f4ccf3be
Also experienced the long boot issue and worked around by downgrading the bios. For a while i thought that the bios upgrade bricked the computer. It’s not obvious that one should let the inital boot phase run for that long, so my instinct was to reboot and try booting the fallback Fedora Silverblue image (which unsurprisingly also looked stuck), then a live flash disk.
I did open this thread prior to upgrading but i TL;DR’d away before the slow boot got mentioned. IMO it isn’t visible enough. I would suggest updating the firmware release banner that shows during fwupdmgr upgrade to mention this problem, and/or perhaps @Quin_Chou could you edit the first post in this thread to mention the problem there?
I’ve noticed a significant increase in POST-to-booting on Windows 11. It seems to get hung at the Windows Boot Manager (or whatever the environment is called - basically the invisible piece that does the work GRUB does for Linux). The Framework POST logo shows for up to a minute before the rotating “booting” circle appears, indicating that the EFI has handed the CPU over to the windows install. Notably, this does not seem to be memory training - that exhibits as an extended blank screen before the POST screen appears.
Very strange. This is the first report of a Windows 11 boot slowdown I’ve read about. After powering down and then pressing the power button, my Windows 11 install, 25H2 and running off a WD SN850X, is at the login screen in 31-32 seconds, with 2-3sec of black screen between framework logo and login screen.
Any connected external drives or USB/TB devices?