seiichi
July 3, 2026, 10:53pm
1
Hi.
After updating to kernel 7.0.14-201, my PCs stopped hibernating. The previous kernel 7.0.13-200 could hibernate and resume without problems.
Any advice on how to hibernate again?
After updating to kernel 7.0.14-201, the system cannot hibernate. The systemctl hibernate command returns an error message as shown below :
seiichi@fedora:~$ uname -a
Linux fedora 7.0.14-201.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jul 1 13:34:38 UTC 2026 x86_64 GNU/Linux
seiichi@fedora:~$ systemctl hibernate
Call to Hibernate failed: Sleep verb 'hibernate' is not configured or configuration is not supported by kernel
The “Call to Hibernate failed: Sleep verb …” message is known as a sign of secure boot. While secure boot is off, I am getting this message.
It hibernates as before.
I have followed the procedure in Fedora 43 Hibernation Setup · GitHub .
With kernel 7.0.13-200, it hibernated and resumed smoothly.
seiichi@fedora:~$ uname -a
Linux fedora 7.0.13-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 19 22:51:30 UTC 2026 x86_64 GNU/Linux
Not only the PC with an Intel 11th gen CPU, but also the PC with an Intel 12th gen CPU has this problem.
After the update, I rolled back the kernel from the boot menu. But I could not solve this problem. Software outside the kernel might prevent hibernation…
seiichi@fedora:~$ systemctl hibernate
Call to Hibernate failed: Sleep verb 'hibernate' is not configured or configuration is not supported by kernel
seiichi@fedora:~$ uname -a
Linux fedora 7.0.13-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 19 22:51:30 UTC 2026 x86_64 GNU/Linux
Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.1
KDE Frameworks Version: 6.27.0
Qt Version: 6.11.1
Kernel Version: 7.0.14-201.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz
Memory: 8 GiB of RAM (7.4 GiB usable)
Graphics Processor: Intel® Iris® Xe Graphics
Manufacturer: FUJITSU CLIENT COMPUTING LIMITED
Product Name: FMVU3403AP
seiichi
July 8, 2026, 10:13pm
2
Update. Bitwarden was preventing hibernation.
opened 08:01AM - 05 Jul 26 UTC
bug
desktop
### Steps To Reproduce
Prerequisites:
- System must have swap/swapfile configur… ed to hibernate, as well as other distro-specific hibernate configuration if any (e.g. SELinux on Fedora systems)
Steps:
1. Open Bitwarden (RPM, Flatpak, AppImage) with an account logged in
2. Run `systemctl hibernate` or `systemctl suspend-then-hibernate` in the terminal
### Expected Result
Hibernate & `suspend-then-hibernate` succeed without errors, both when called from the terminal using `systemctl` and when called from the DE-configured triggers.
Additionally, when Bitwarden is up and running, `/sys/power/disk` should look normal:
```
cat /sys/power/disk
[platform] shutdown reboot suspend test_resume
```
This was the behavior in the past, until v2026.5.0 (and I believe v2026.6.0?).
### Actual Result
Hibernate & `suspend-then-hibernate` fails:
```
> systemctl hibernate
Call to Hibernate failed: Sleep verb 'hibernate' is not configured or configuration is not supported by kernel
> systemctl suspend-then-hibernate
Call to SuspendThenHibernate failed: Sleep verb 'suspend-then-hibernate' is not configured or configuration is not supported by kernel
```
Additionally, `/sys/power/disk` outputs the following:
```
cat /sys/power/disk
[disabled]
```
This is the behavior in the current version (v2026.6.1).
As of right now, exiting Bitwarden restores the correct `/sys/power/disk` entries (shown in video), and after this, hibernate & `suspend-then-hibernate` succeeds (not shown in video).
### Screenshots or Videos
https://github.com/user-attachments/assets/e4428f68-9b17-4d4c-9fac-11d5f9dc08f7
### Additional Context
Tested on 3 devices running Fedora Linux 44 (Silverblue) over the past 2 days. I first observed this behavior after updating my Silverblue systems on July 3; previously my systems were on June 26 Silverblue deployments (I believe my June 26 deployments had v2026.6.0 RPM).
Downgrading to a previous system deployment with the v2026.6.0 RPM installed did not fix the issue. Flatpak and AppImage versions also causes the issue on my 3 machines.
I did observe in one machine that when the Flatpak is freshly installed, and no account has been logged in yet, `/sys/power/disk` looks normal - not `[disabled]` - even when Bitwarden is running. However, once an account has been logged in, `/sys/power/disk` shows `[disabled]`.
---
The RPM file & AppImage files downloaded from the Bitwarden website and/or Bitwarden Github; Flatpak package is installed from Flathub.
```
rpm -qi bitwarden
Name : bitwarden
Version : 2026.6.1
Release : 1
Architecture: x86_64
Install Date: Sat 04 Jul 2026 01:42:34 PM WIB
Group : default
Size : 379329490
License : GPL-3.0
Signature : (none)
Source RPM : bitwarden-2026.6.1-1.src.rpm
Build Date : Tue 30 Jun 2026 10:26:49 PM WIB
Build Host : runnervmfmtub.fmczizre0mhe1fy4eo11s1yo2g.gx.internal.cloudapp.net
Relocations : /
Packager : Bitwarden Inc. <hello@bitwarden.com>
Vendor : Bitwarden Inc. <hello@bitwarden.com>
URL : https://bitwarden.com
Summary : A secure and free password manager for all of your devices.
Description :
A secure and free password manager for all of your devices.
```
In-app settings that might be of interest:
- **Unlock with PIN**: Enabled
- **Use hardware acceleration**: Enabled & Disabled produces the same result
- **Enable SSH agent**: Enabled
### Operating System
Linux
### Operating System Version
Fedora Linux 44.20260705.0 (Silverblue)
### Installation method
Direct Download (from bitwarden.com), Flatpak, Other
### Build Version
Version 2026.6.1 SDK 'main (c5d5bba)' Shell 39.8.5 Renderer 142.0.7444.265 Node 22.22.1 Architecture x64
### Issue Tracking Info
- [x] I understand that work is tracked outside of GitHub. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
As a tentative workaround, add followings to ~/.bashrc solves this problem.
export SECURE_KEY_CONTAINER_BACKEND=mlock