System Information
- Model: Framework Laptop 12, 13th Gen Intel Core i5-1334U (rev A5)
- BIOS: 03.07 (latest)
- OS: Fedora Linux 43 (Rawhide)
- Kernel: tested on both 7.0.12-101.fc43 and 7.1.3-100.fc43 — identical behaviour on both
- Desktop: KDE Plasma 6, Wayland
- Swap: 17 GB Btrfs swapfile,
nodatacowset, correct SELinux context (swapfile_t)
Problem
When hibernating using the default platform mode (/sys/power/disk = [platform]), the system writes the hibernate image successfully and syncs filesystems, then hangs indefinitely. The screen goes black, the power light stays solid, and the system is completely unresponsive — including to keyboard input and the power button. A forced reboot via long power button press is required every time.
This has been reproduced consistently across two kernel versions, ruling out a kernel regression.
Similar Reports on Other Framework Models
Framework Laptop 13 users (both Intel 13th Gen and Ryzen 7040) have reported the same symptom: system gets stuck after hibernation with the power light on and no response to any input. The ArchWiki documents this as a known firmware class issue affecting multiple laptop vendors and recommends HibernateMode=shutdown as the standard Linux-side workaround.
Worth noting: BIOS 3.06 for the FW12 included “Fixed an issue where the fan was not detected when powering on from S4/S5”, which confirms active work on the S4 code path in the FW12 firmware.
Diagnostics
The kernel log ends abruptly after filesystem sync with no power-off confirmation:
Jul 08 21:43:58 kernel: PM: hibernation: hibernation entry
Jul 08 21:43:58 kernel: Filesystems sync: 0.049 seconds
[log ends — system hung, no hibernation exit, no power-off]
On the next boot (after forced reboot), the hibernate resume generator confirmed the image had been written successfully before the hang:
systemd-hibernate-resume-generator: Reported hibernation image:
ID=fedora VERSION_ID=43 kernel=7.0.12-101.fc43.x86_64
UUID=19ded223-... offset=46169698
kernel: PM: Image not found (code -22)
The -22 is expected — the forced reboot invalidated the image. The key point is that the resume generator detected a valid image, confirming the write completed before the firmware hang. Reproduced identically on kernel 7.1.3.
Additional Finding — zram blocks hibernate entirely
With zram active as a higher-priority swap device (default on Fedora), hibernate fails immediately before even writing an image:
systemd-sleep: Failed to put system to sleep. System resumed again: Device or resource busy
A swapoff /dev/zram0 before hibernating is required. This is not documented in Framework’s official Fedora hibernation guide and will silently block hibernation for anyone with the default Fedora swap configuration.
Question for Framework
Is the ACPI S4 power-off hang a known limitation of the current firmware, or something that could be addressed in a future BIOS update? The platform mode represents the correct ACPI S4 flow and would be the preferred long-term path if the firmware’s S4 implementation can be corrected. I can change it to shutdown but I’m reluctant to create errors on a non-graceful shutdown.
Thank you