Skip to content

Instantly share code, notes, and snippets.

@eloylp
Last active March 25, 2024 15:47
Show Gist options
  • Star 66 You must be signed in to star a gist
  • Fork 7 You must be signed in to fork a gist
  • Save eloylp/b0d64d3c947dbfb23d13864e0c051c67 to your computer and use it in GitHub Desktop.
Save eloylp/b0d64d3c947dbfb23d13864e0c051c67 to your computer and use it in GitHub Desktop.
Fedora 35 hibernation with swapfile, only for hibernation and resume

Fedora35 hibernation

This guide helps to configure the hibernation on a default Fedora35 (also worked fine in previous Fedora34) installation by using a swap file. The Fedora35 installation comes with btrfs as default filesystem. Also, it comes with a zram swap device:

$ swapon
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition   8G   0B  100

This device reserves a physical memory area in which all the content will be compressed (at its input) and uncompressed (at its output). But, we cannot hibernate with this type of swap space as it is only in memory.

After feedback received from contributors of this guide, seems we can say that this guide will work in both, encrypted and unencrypted setups.

important note before you continue: Some of us are experimenting problems with nvidia proprietary drivers. See below comments for more information on the investigation.

Motivation

Nowadays we have lots of RAM in our laptops. In my case, a guy with a laptop for programming, i only use swap space for hibernation. When i move from one location to another, i dont want to loose all my open stuff nor consuming battery while i am moving.

I want to preserve the zram swap device of the default configuration.

Solution

This are the steps we need to perform in our system:

  1. The hibernation is triggered by the user.
  2. The swap file is activated.
  3. The zram device is deactivated. If there are any memory pages present in zram, they will be moved to the activated (2) swap file.
  4. Hibernate the laptop.

And the following sequence for resuming:

  1. Power on the computer.
  2. Restore system state from the swap file at boot time.
  3. Activate the zram device.
  4. Deactivate the swap file. That could cause the zram device to start compressing data.

Seems there are efforts in order to make this much better, even with dynamic sized swap files, so only generating swap files for hibernation with the needed size on each moment, and more user friendly.

This guide will make use of a fixed size swap file, since probably for going further is better to just contribute in the mentioned systemd issue .

Steps

Default Fedora35 installations comes with btrfs as default filesystem. Such file system comes with the subvolume feature. Subvolumes are not partitions. They are just a logical separations of a filesystem at a file level. Some kind of operations like snapshots, will try to include the swap file. We need to prevent this by isolating the swap file into its own subvolume:

btrfs subvolume create /swap

The above will ensure the swap file will not be taken into account in other snaphots as they are not recursive in other subvolumes.

Next is to create our swapfile for hibernation. Ensure the specified size is enough for saving the contents of the RAM + the uncompressed contents of the zram swap space. How to determine the size ? that might be a rough estimation per use case. As root:

touch /swap/swapfile
chattr +C /swap/swapfile  ## Needed to disable Copy On Write on the file.
fallocate --length 33GiB /swap/swapfile  ## Please, calculate your size as mentioned in above comments.
chmod 600 /swap/swapfile 
mkswap /swap/swapfile 

Now lets prepare the path of the resume operation. We need add to the initramfs the necessary modules for resuming the system. We need to create a new file at /etc/dracut.conf.d/resume.conf with the following content:

add_dracutmodules+=" resume "

After that we need to regenerate the initramfs:

dracut -f

Next, we have to add the resume and resume_offset into the GRUB_CMDLINE_LINUX, so that Grub can instruct the kernel coordinates where the swap file resides, in order to resume the system.

For gathering the resume param we need the partition UUID in which the swap file is stored:

$ findmnt -no UUID -T /swap/swapfile
dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8

Now lets gather the last needed data, we need the resume_offset. That is, the physical offset of our swap file in the file system. For doing that, we need to follow this guide.

Now we need to instruct GRUB to initialize the kernel with this coordinates. Edit the /etc/defaut/grub and grab there the parameters we just calculated:

GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-4369a407-2be1-4f37-9764-ff848a0f2089 resume=UUID=dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8 resume_offset=2459934 rhgb quiet"

Now lets re-configure the grub (UEFI setup assumed):

grub2-mkconfig -o /boot/grub2/grub.cfg

Note: We only want the swap file to be used when the hibernation takes place and in the resume stage. we are not going to configure fstab entries. To achieve that, one of the options is to use systemd. We are going to configure 2 systemd services. One for preparing the hibernation and the other one for resuming it:

For enabling the swap file and disabling the zram swap device before hibernation, lets create the file /etc/systemd/system/hibernate-preparation.service:

[Unit]
Description=Enable swap file and disable zram before hibernate
Before=systemd-hibernate.service

[Service]
User=root
Type=oneshot
ExecStart=/bin/bash -c "/usr/sbin/swapon /swap/swapfile && /usr/sbin/swapoff /dev/zram0"

[Install]
WantedBy=systemd-hibernate.service

The order is important in the above service definition. First of all we enable the swap file, which should have enough space to store the contents of the "in use RAM", plus the contents of the uncompressed zram swap device. Secondly, we disable the zram swap device. At that moment, the kernel will start moving all the memory pages from the zram swap device to the swap file if needed. After all of that, the hibernation will take place only in the swap file. Last step for the above script to have effect is to install this service in systemd:

# systemctl enable hibernate-preparation.service
Created symlink /etc/systemd/system/systemd-hibernate.service.wants/hibernate-preparation.service → /etc/systemd/system/hibernate-preparation.service.

We need to disable the swap file when the system just resumed. Lets create the /etc/systemd/system/hibernate-resume.service file:

[Unit]
Description=Disable swap after resuming from hibernation
After=hibernate.target

[Service]
User=root
Type=oneshot
ExecStart=/usr/sbin/swapoff /swap/swapfile

[Install]
WantedBy=hibernate.target

Then enable it by:

# systemctl enable hibernate-resume.service

Created symlink /etc/systemd/system/hibernate.target.wants/hibernate-resume.service → /etc/systemd/system/hibernate-resume.service.

In order to make the suspend-then-hibernate sequence to work, please take a look at this great comment and follow the instructions there.

In order to avoid false positives regarding to swap space, due to the zram device existence, we need to disable some checks:

mkdir -p /etc/systemd/system/systemd-logind.service.d/
cat <<-EOF | sudo tee /etc/systemd/system/systemd-logind.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF

mkdir -p /etc/systemd/system/systemd-hibernate.service.d/
cat <<-EOF | sudo tee /etc/systemd/system/systemd-hibernate.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF

Now you must reboot your computer, in order the steps until here take effect.

We also need to allow systemd-sleep system to read the swap file in SELinux . One option for allowing this is to make it fail. After that, use the audit2allow to do the white listing. Lets go step by step:

  1. Try to hibernate:

    # systemctl hibernate

    This should fail right now. Probably returning you to the display manager login. Also, logging details at /var/log/audit/audit.log .

  2. We can check the event happened with audit2allow inspecting the log, it will ouput something similar to this entry among others:

    # audit2allow -w -a
    
    type=AVC msg=audit(1630262756.460:2098): avc:  denied  { search } for  pid=26180 comm="systemd-sleep" name="swap" dev="dm-0" ino=256 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
    	Was caused by:
    		Missing type enforcement (TE) allow rule.
    
    		You can use audit2allow to generate a loadable module to allow this access.3.
  3. To see what rule we must allow, just type:

    # audit2allow -b
    
    #============= systemd_sleep_t ==============
    allow systemd_sleep_t unlabeled_t:dir search;

    The above rule should be the only one in the output. If not, we could be white listing other elements by accident.

  4. Instruct SELinux to allow further attemps by executing the following commands:

    # cd /tmp
    # audit2allow -b -M systemd_sleep
    ******************** IMPORTANT ***********************
    To make this policy package active, execute:
    
    semodule -i systemd_sleep.pp
    
    # semodule -i systemd_sleep.pp

We should be ready to hibernate now. Lets just try it by:

# systemctl hibernate

After resuming, the swap file should be deactivated, so continuing with the default zram swap device setup:

$ swapon
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition   8G   0B  100

As a bonus, you can enable gnome environment hibernate buttons by installing this extension.

Please check that all your devices state are properly restored after resuming.

Troubleshooting

If you are having unexpected problems, inspectioning the journal will be of help to see errors in systemd scripts:

journalctl -f
@jorp
Copy link

jorp commented May 28, 2022

Hi all, just wanted to share a playbook I made back in August for Fedora 34. I also have a corresponding blog post here.

@ameeno
Copy link

ameeno commented Jun 10, 2022

Hi all, just wanted to share a playbook I made back in August for Fedora 34. I also have a corresponding blog post here.

Thanks for this playbook. its useful however it adds swap to fstab, (which this guide does not do) also your calculations for swap file size is not taking into account the zram size and so is creating a swapfile of 16gb for 16gb of ram.

it also isnt doing the suspend-then-hibernate changes nor is it adding the selinux allows. so not got this working yet (can hibernate but not resume) very weird

@pietryszak
Copy link

I create a bash script, based on @jorp solution and information on this gist provided by @eloylp and comment by @miXwui.
It's test version and I test it at vm on VMWare. Works fine. Please help me with test, if you have a machine to do this. Please remember that something can go wrong.
https://github.com/pietryszak/fedora-hibernation

@krokwen
Copy link

krokwen commented Jul 4, 2022

just finished setup for F36.
new issues has arrived.

This happens when hibernate-resume service is enabled:
Failed to find location to hibernate to: Function not implemented
Failed to prepare for hibernation: Function not implemented

Because somehow it runs before hibernation itself, and hibernation loses hibernation location.
Finally, just disabled this service, and hibernation become working.

But now i have to fix disabling swap-file on resume...

After I fix this, I will start working on suspent-then-hibernate and hybrid-sleep, and will pack everything as rpm.

Thank you for your guide, it was working flawlessly on my full-amd rog 15 on F34.

For now tested on r5 5500u asus zenbook uw424u.

Current script for hibernation setup (WIP); It's fully automated; used grubby, because in f36 we no longer have a single grub.cfg, but slices per-core; automated generation of selinux policy, and usage of bmp C program.

https://pastebin.com/nLSkaMQZ

UPD:
just tested hibernate-resume one more time, and it works...

@quiteBold
Copy link

quiteBold commented Sep 7, 2022

Hi all.

I just tried on Fedora 36 with an encrypted drive.

$ sudo systemctl hibernate
Failed to hibernate system via logind: Sleep verb "hibernate" not supported
$ sudo journalctl -b
kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7

Seems like the kernel is locked regarding using an unencrypted swap file, though the swap-file lies in an luks-encrypted volume. Does anyone have a hint / solution at hand?
(I use secure boot and want to stay with it)

Thanks in advance
Simon

@miXwui
Copy link

miXwui commented Sep 7, 2022

Hey y'all, it's been a while! (in this comment: hibernation/resume debugging tips + my issue and solution)

@eloylp and @w4tsn I'm glad my info helped, and @w4tsn I happened upon your Fedora Magazine article -- great article! Next time I need to setup hibernation, I will either refer to that and/or test out @pietryszak's script.


So a couple months ago, my system (Framework Laptop i7-1165G7) started freezing on hibernation resume (either black screen with just an underscore _ or sometimes it would show the kernel version, something like Fedora_5.19.6-200.fc36.x86_64 (that's not exactly what it said). Not every time, but a lot of the times.

It seemed like it was hard freezing when loading the kernel, so I couldn't Magic SysRq or drop/switch into a terminal.

I finally did some digging today, and happened upon this great article from Intel on best practices to debug suspend/hibernate issues:
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
Note sections 2.1 initcall_debug and 2.3 ignore_loglevel and also this https://stackoverflow.com/a/37283021 answer.

So I added this to my kernel parameters:

ignore_loglevel=1 initcall_debug=1

And upon system boot/hibernation resume/kernel loading, debug logs appear. I was able to see where hibernation resumption got stuck -- the last few lines printed were:

intel_ish_ipc 0000:00:12.0: [ishtp-ish]: Timed out waiting for FW-initiated reset
intel_ish_ipc 0000:00:12.0: ISH: hw start failed.
initcall ish_driver_init+0x0/0x1000 [intel_ish_ipc] returned 0 after 219091 usecs

So I did some digging, and found these (just dumping links here for reference to this particular issue and feel free to ignore)
https://www.reddit.com/r/linuxquestions/comments/fzyvvy/comment/ful8814
https://www.reddit.com/r/Ubuntu/comments/wpx7pn/intel_ish_ipc_000000130_ishtpish_timed_out/
https://forums.developer.nvidia.com/t/ubuntu-20-04-boot-to-black-screen-when-selecting-nvidia-as-prime-after-kernel-update/219727
https://www.supermicro.com/support/faqs/faq.cfm?faq=31505
https://bugzilla.kernel.org/show_bug.cgi?id=198543
https://bugzilla.kernel.org/show_bug.cgi?id=117641
https://bbs.archlinux.org/viewtopic.php?id=277709
https://www.thomas-krenn.com/en/wiki/Resolve_mei:_Init_hw_failure_or_mei:_initialization_failed

To fix the issue, I simply blacklisted the intel_ish_ipc module by adding this kernel parameter:

modprobe.blacklist=intel_ish_ipc

though it should also work by adding this to e.g. /etc/modprobe.d/blacklist.conf (or best-practice-naming as /etc/modprobe.d/intel_ish_ipc.conf

blacklist intel_ish_ipc

After blacklisting, my system no longer freezes on that module and resumes normally!
Though it seems that the intel_ish_ipc module still loads afterwards since it's a dependent module for intel_ishtp:

lsmod | grep ish
intel_ishtp            61440  2 intel_ishtp_hid,intel_ish_ipc

Hopefully this helps others know how to more thoroughly debug hibernation resumption issues and/or solve the issue with a faulty module. For anyone wondering, I'm still not sure if my issue was caused by a kernel regression, a Framework BIOS update, a Fedora update, or something else.
Edit (Sept 7, 2022): though from seeing others have issues recently on other systems, I tend to believe it stems from a recent kernel regression
Edit (Nov 20, 2022): after updating to Fedora 37 (6.0.10-300.fc37.x86_64) my hibernation setup still works, though unfortunately it seems that the resumption issues with intel_ish_ipc remain.
Edit (Nov 05, 2022): as of Oct 31, 2023, hibernation and suspend-to-hibernate continued to work flawlessly on Fedora 38 (I had kept intel_ish_ipc on the blacklist). I swapped to an AMD 7080U mainboard, finally removed modprobe.blacklist=intel_ish_ipc, and thankfully things are still working.

@ceiphr
Copy link

ceiphr commented Dec 7, 2022

Hello!

I wanted to say, thank you to everyone, this guide is fantastic!

I'm on a Framework running Fedora 37. Everything works and @miXwui's fix for intel_ish_ipc helped a ton!

Going off what @quiteBold mentioned, I too would love to see this working with secure boot and kernel lockdown enabled. Having a secure system is something I value. I wish I could have my cake and eat it too in this situation.

With that being said, I do have a small question. I'm on a system with LUKS encryption. Given the swap is on the disk, is it safe to assume it's encrypted too since it isn't on a separate partition? I feel like it's safe to assume the swap is encrypted given I have to decrypt the drive after waking from hibernation, but I thought I'd ask anyway.

@eloylp
Copy link
Author

eloylp commented Dec 15, 2022

@ceiphr thanks for your comment and question. You are right.

The swap file containing the OS state resides in the encripted btrfs partition, so in order to be accessed, the LUKS password its needed. I think we can assume its safe in terms of encryption.

Thank you everyone for all the great contributions !

@w4tsn
Copy link

w4tsn commented Dec 16, 2022

@ceiphr @quiteBold @eloylp if secure boot is enabled and the kernel is in lockdown mode (>=5.4) it refuses to suspend to a swap file more because it can't verify it rather than it being unencrypted (a bit misleading error message there). The kernel does not care if the hibernation store is encrypted or not. In lockdown certain APIs are restricted on the highest levels - even for root - as a security measure. When the system state and kernel are stored on disk state which was previously protected by lockdown would now be exposed to modifications. Without proper verification upon returning from hibernation this can't be done properly. That is why there is an effort to produce signed and verifiable hibernation images, but sadly we are not there yet. An encrypted disk does not solve this issue because after decryption in initramfs and right on storing the image before going to sleep you could modify the image from userland.

As on modern business notebooks with Fedora and enabled Secure Boot (which is enabled by default) this lockdown problem applies the FedoraMagazine article is prepended with a short warning message.

@ceiphr
Copy link

ceiphr commented Dec 25, 2022

@eloylp thank you for the reassurance!

@w4tsn thank you for the thorough response, that makes a lot of sense! Hopefully, we will see developments with this in the future.

For now, here are some interesting developments I've found related to this topic:

@alexspurling
Copy link

alexspurling commented Jan 10, 2023

I think the description already specifies an idea on how to calculate the space for the swap file. However, i added a comment in the code for the quick reader.

Firstly, thank you very much for the very well explained tutorial. Could you please explain this further? The article says you should ensure the size of the swap file "is enough for saving the contents of the RAM + the uncompressed contents of the zram swap space", but how can we calculate the uncompressed size of the contents of zram? As I understand, it will depend on the exact data that is stored as well as the selected compression algorithm.

I have 32GB of ram, an 8GB zram file using LZO-RLE compression. How can I calculate the required size of the swap file?

@eloylp
Copy link
Author

eloylp commented Jan 11, 2023

Hello @alexspurling

Thank you for taking time of writing ! Yeah, you are right. That will depend on each use case/setup. I think the idea was to provide a rough estimation, trying to be generous with the size. But it was not clear in the guide. I just fixed that.

I am not sure if this is something we could profile in an easy way. Probably it doesn't worth the effort. I think its something we can always adjust on demand, as we are not dealing with fixed partitions, but with a swap file we can reconfigure later on, after the initial setup.

Many thanks for your contribution !

@stephane-klein
Copy link

stephane-klein commented Feb 17, 2023

Hello,

I have executed all the instructions indicated in the guide Fedora35 hibernation that I found on Fedora Magazine.

  • My laptop: Thinkpad T14s Gen 3 AMD
  • OS: Fedora 37, totally up to date, freshly installed this morning
  • Secure Boot disable in BIOS
  • volume LUKS encryption enabled
# neofetch
             .',;::::;,'.                root@MiWiFi-R4A-srv 
         .';:cccccccccccc:;,.            ------------------- 
      .;cccccccccccccccccccccc;.         OS: Fedora Linux 37 (Workstation Edition) x86_64 
    .:cccccccccccccccccccccccccc:.       Host: 21CQCTO1WW ThinkPad T14s Gen 3 
  .;ccccccccccccc;.:dddl:.;ccccccc;.     Kernel: 6.1.11-200.fc37.x86_64 
 .:ccccccccccccc;OWMKOOXMWd;ccccccc:.    Uptime: 9 mins 
.:ccccccccccccc;KMMc;cc;xMMc:ccccccc:.   Packages: 1854 (rpm) 
,cccccccccccccc;MMM.;cc;;WW::cccccccc,   Shell: bash 5.2.15 
:cccccccccccccc;MMM.;cccccccccccccccc:   Resolution: 1920x1200 
:ccccccc;oxOOOo;MMM0OOk.;cccccccccccc:   WM: Mutter 
cccccc:0MMKxdd:;MMMkddc.;cccccccccccc;   WM Theme: Adwaita 
ccccc:XM0';cccc;MMM.;cccccccccccccccc'   Theme: Adwaita [GTK3] 
ccccc;MMo;ccccc;MMW.;ccccccccccccccc;    Icons: Adwaita [GTK3] 
ccccc;0MNc.ccc.xMMd:ccccccccccccccc;     Terminal: gnome-terminal 
cccccc;dNMWXXXWM0::cccccccccccccc:,      CPU: AMD Ryzen 7 PRO 6850U with Radeon Graphics (16) @ 2.700GHz 
cccccccc;.:odl:.;cccccccccccccc:,.       GPU: AMD ATI Radeon 680M 
:cccccccccccccccccccccccccccc:'.         Memory: 2017MiB / 30846MiB 
.:cccccccccccccccccccccc:;,..
  '::cccccccccccccc::;,.                

Problems encountered:

  • the resuming take 2min after entering my LUKS encryption password
  • wifi not working after resuming

Here is the systemd journal content: https://gist.github.com/stephane-klein/29198d3ed43e01a2ba9d0360e6deedd8

Do you know how to fix this issues?

Best regards,
Stéphane


Note: same post on Thinkpad Subreddit and Ask Fedora Forum

@stephane-klein
Copy link

stephane-klein commented Mar 1, 2023

In my dmesg (click to see full content), I see:

[  213.051537] Call Trace:
[  213.051539]  <TASK>
[  213.051541]  ieee80211_do_stop+0x647/0x8b0 [mac80211]
[  213.051591]  ieee80211_stop+0x49/0x170 [mac80211]
[  213.051633]  __dev_close_many+0x8e/0xf0
[  213.051642]  dev_close_many+0x7b/0x120
[  213.051648]  ? ieee80211_handle_reconfig_failure+0x69/0x90 [mac80211]
[  213.051696]  dev_close+0x59/0x80
[  213.051701]  cfg80211_shutdown_all_interfaces+0x49/0xf0 [cfg80211]
[  213.051742]  wiphy_resume+0x94/0x150 [cfg80211]
[  213.051780]  ? wiphy_suspend+0x2b0/0x2b0 [cfg80211]
[  213.051840]  dpm_run_callback+0x4a/0x150
[  213.051845]  device_resume+0xa2/0x1f0
[  213.051848]  async_resume+0x19/0x30
[  213.051852]  async_run_entry_fn+0x30/0x130
[  213.051856]  process_one_work+0x1c7/0x380
[  213.051859]  worker_thread+0x4d/0x380
[  213.051862]  ? rescuer_thread+0x380/0x380
[  213.051864]  kthread+0xe9/0x110
[  213.051868]  ? kthread_complete_and_exit+0x20/0x20
[  213.051873]  ret_from_fork+0x22/0x30
[  213.051880]  </TASK>
[  213.051881] ---[ end trace 0000000000000000 ]---
[  213.051903] ------------[ cut here ]------------

...

[  213.052301] ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume+0x0/0x150 [cfg80211] returns -11
[  213.052317] ieee80211 phy0: PM: failed to restore async: error -11

I don't know if this detail is usefull to fix my issue :thinking: .

@stephane-klein
Copy link

In my dmesg (click to see full content), I see:

I see also :

[  210.043130] ath11k_pci 0000:01:00.0: failed to resume mhi: -5
[  210.043134] ath11k_pci 0000:01:00.0: failed to resume hif during resume: -5
[  210.043136] ath11k_pci 0000:01:00.0: failed to resume core: -5
[  210.043138] ath11k_pci 0000:01:00.0: PM: dpm_run_callback(): pci_pm_restore+0x0/0xe0 returns -5
[  210.043158] ath11k_pci 0000:01:00.0: PM: failed to restore async: error -5
[  213.050611] ath11k_pci 0000:01:00.0: wmi command 16387 timeout
[  213.050624] ath11k_pci 0000:01:00.0: failed to send WMI_PDEV_SET_PARAM cmd
[  213.050632] ath11k_pci 0000:01:00.0: failed to enable dynamic bw: -11

@stephane-klein
Copy link

@mt190502
Copy link

mt190502 commented Mar 5, 2023

In my dmesg (click to see full content), I see:

[  213.051537] Call Trace:
[  213.051539]  <TASK>
[  213.051541]  ieee80211_do_stop+0x647/0x8b0 [mac80211]
[  213.051591]  ieee80211_stop+0x49/0x170 [mac80211]
[  213.051633]  __dev_close_many+0x8e/0xf0
[  213.051642]  dev_close_many+0x7b/0x120
[  213.051648]  ? ieee80211_handle_reconfig_failure+0x69/0x90 [mac80211]
[  213.051696]  dev_close+0x59/0x80
[  213.051701]  cfg80211_shutdown_all_interfaces+0x49/0xf0 [cfg80211]
[  213.051742]  wiphy_resume+0x94/0x150 [cfg80211]
[  213.051780]  ? wiphy_suspend+0x2b0/0x2b0 [cfg80211]
[  213.051840]  dpm_run_callback+0x4a/0x150
[  213.051845]  device_resume+0xa2/0x1f0
[  213.051848]  async_resume+0x19/0x30
[  213.051852]  async_run_entry_fn+0x30/0x130
[  213.051856]  process_one_work+0x1c7/0x380
[  213.051859]  worker_thread+0x4d/0x380
[  213.051862]  ? rescuer_thread+0x380/0x380
[  213.051864]  kthread+0xe9/0x110
[  213.051868]  ? kthread_complete_and_exit+0x20/0x20
[  213.051873]  ret_from_fork+0x22/0x30
[  213.051880]  </TASK>
[  213.051881] ---[ end trace 0000000000000000 ]---
[  213.051903] ------------[ cut here ]------------

...

[  213.052301] ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume+0x0/0x150 [cfg80211] returns -11
[  213.052317] ieee80211 phy0: PM: failed to restore async: error -11

I don't know if this detail is usefull to fix my issue thinking .

Same issue

@stephane-klein
Copy link

My laptop: Thinkpad T14s Gen 3 AMD

Problems encountered:

* the resuming take 2min after entering my LUKS encryption password
* wifi not working after resuming

Some issues to follow:

@stephane-klein
Copy link

@dmy3k
Copy link

dmy3k commented Jun 18, 2023

The guide still is relevant for Fedora 38, however some improvements can be done.

With systemd v253 we have possibility to use suspend-then-hibernate that will sleep as long as possible. When battery enters low-charge state (5%) system will hibernate. This is beneficial for several use cases, e.g sleep between business hours, sleep on AC with closed lid, as this will avoid entering hibernate. Corresponding systemd pull requests #23895, #25374

However, SElinux module to support the above is not shipped with os, logging errors in journalctl

Jun 16 07:38:38 fedora audit[3100]: AVC avc:  denied  { read } for  pid=3100 comm="systemd-sleep" name="+power_supply:BAT0" dev="tmpfs" ino=1650 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=0

Jun 16 21:26:09 fedora audit[71808]: AVC avc:  denied  { write } for  pid=71808 comm="systemd-sleep" name="systemd" dev="dm-0" ino=143877 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=dir permissive=0

We can update systemd_sleep module with audit2allow as shown in the guide above. Alternatively here is a gist to automate this

@tstoeckler
Copy link

Note that there's also a guide for Silverblue: https://discussion.fedoraproject.org/t/setup-hibernation-on-silverblue-kionite/78834/8

Not sure if anything mentioned there, for example the btrfs commands, could be used in the guide here, as well, but in any case I hadn't realized that I need to use /var/swap/swapfile as a swapfile path, which (presumably) is why I couldn't get this to work on Silverblue.

@00sapo
Copy link

00sapo commented Oct 12, 2023

Great gist! I managed to get it working with nvidia drivers using the script in this commnet. However, just systemctl enable nvidia-{suspend,resume,hibernate} worked for hibernation only, but not for suspend-then-hibernate.

I think we could set up a repo with a small script to ease the set up. Arguments should be the drive where the directory should be created and the size of if. --nvidia could be added as optional.

@obitbef
Copy link

obitbef commented Dec 6, 2023

Please note that comment. It seems that deactivating zram and activating swapfile on hibernate and vice versa is not required.

You do not need to deactivate zram, since the hibernation logic in systemd ignores zram devices anyway when looking for a swap device to hibernate into.

if you have a swap file anyway, then just activate it always, but make sure to give it a lower priority than your zram device, so that zram is always preferred, and the swap file is only used if the system is under pressure enough that zram didn#t work. That will give you overall better behaviour.

@enmyj
Copy link

enmyj commented Dec 9, 2023

I'm sure I'm wrong here but based on the above linked comment, it seems like a bunch of config is no longer required here. I'm on Fedora 39 and systemd version 254 and I'm able to hibernate with the following setup:

  • create the swap subvolume, add it to /etc/fstab with low priority, swapon /swap/swapfile
  • I kept the memory check overrides and the dracut config, not clear if that's still necessary
  • I updated the selinux script posted above to include permissions for efivars:
allow systemd_sleep_t swapfile_t:dir search;
allow systemd_sleep_t efivarfs_t:file { create setattr getattr ioctl open read write };
allow systemd_sleep_t efivarfs_t:dir { add_name create write };

So basically, I'm able to hibernate with minimal config in /etc/systemd/* and without any kernel arguments 👍

@mardoodmuh
Copy link

mardoodmuh commented Dec 27, 2023

Hi, i am using Fedora workstation 39.
I followed the instructions of the first comment and now my system is not booting.

IMG_20231227_110321

62f7aa3b-6a00-4efd-b0ac-9816cd0cce79

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment