DEV Community

Andy Mindful
Andy Mindful

Posted on

How to Set Up Reliable Hibernation on Fedora 43 with LUKS and NVIDIA

#linux #fedora #hibernate

A practical setup for a modern Linux laptop with Windows dual boot, encrypted storage, dedicated swap, dracut, and hybrid Intel/NVIDIA graphics

Hibernation on Linux sounds simple in theory:

Save RAM to disk, power the machine off, then restore the memory image on the next boot.

On a modern laptop, however, several independent layers have to cooperate:

Firmware / UEFI
        ↓
Linux kernel
        ↓
Encrypted storage
        ↓
Disk-backed swap
        ↓
Kernel resume target
        ↓
initramfs / dracut
        ↓
systemd
        ↓
GPU driver
        ↓
Desktop session
Enter fullscreen mode Exit fullscreen mode

If any of those layers is misconfigured, systemctl hibernate may fail, the machine may cold-boot instead of resuming, or the desktop may return in a broken state.

This article describes the configuration I currently use on a Lenovo ThinkPad P1 Gen 7 running Fedora 43.

It is not meant to be a universal recipe for every Linux machine. Instead, it is a known-good baseline that has survived long uptimes, repeated suspend/hibernate cycles, hybrid graphics, Windows dual boot, and normal workstation usage.

The hardware and software

My system is:

Component Configuration
Laptop Lenovo ThinkPad P1 Gen 7
CPU Intel Core Ultra 9 185H
RAM 64 GB
Integrated GPU Intel Arc / Meteor Lake
Discrete GPU NVIDIA GeForce RTX 4070 Laptop, 8 GB
OS Fedora 43 Workstation
Desktop GNOME 49 / Wayland
Kernel Linux 6.12 LTS
NVIDIA 580 production/stable branch
Storage LUKS encrypted
Swap Dedicated disk-backed swap LV, about 74 GB
Other OS Windows 11, dual boot

Two choices here deserve explanation.

Linux 6.12 LTS is not required for hibernation. I use it because power management on laptops with hybrid Intel/NVIDIA graphics tends to benefit from reducing moving parts. The goal of this machine is stability, not running the newest kernel every week.

Likewise, NVIDIA 580 is a stability choice, not a hibernation requirement.

The setup was originally validated on the 6.12 LTS series and remained significantly more predictable than continuously tracking Fedora's latest kernel together with new NVIDIA releases.

1. Before touching Linux: Secure Boot and BitLocker

This configuration assumes:

Secure Boot: OFF
Enter fullscreen mode Exit fullscreen mode

That is intentional.

On this Fedora 43 system, enabling Secure Boot activated kernel lockdown and removed hibernation support from the available kernel sleep states.

With Secure Boot enabled:

cat /sys/power/state
Enter fullscreen mode Exit fullscreen mode

did not expose disk.

With it disabled:

freeze mem disk
Enter fullscreen mode Exit fullscreen mode

became available.

On EFI systems, Secure Boot can automatically enable kernel lockdown. Fedora 43 users have also reported the same practical result: S4 may exist in ACPI while disk is unavailable through /sys/power/state when Secure Boot is active.

Security trade-off

Disabling Secure Boot reduces protection of the early boot chain.

This is therefore not something I recommend doing blindly. It is simply a prerequisite of this particular tested setup.

The hibernation image also contains a snapshot of system memory, potentially including sensitive data. This is one reason I keep the disk-backed swap inside the LUKS-encrypted storage stack.

Windows dual boot and BitLocker

If Windows uses BitLocker, changing UEFI or Secure Boot settings can trigger BitLocker recovery.

Before changing Secure Boot, make sure you have your BitLocker recovery key. I also suspend BitLocker protection before making the firmware change.

Run an elevated PowerShell:

Suspend-BitLocker -MountPoint "C:" -RebootCount 0
Enter fullscreen mode Exit fullscreen mode

Then reboot into UEFI and disable Secure Boot.

After confirming that Windows still boots normally:

Resume-BitLocker -MountPoint "C:"
Enter fullscreen mode Exit fullscreen mode

Microsoft explicitly recommends suspending BitLocker around firmware and Secure Boot related changes because such changes can alter the platform measurements used to release the BitLocker key.

I also disable Windows Fast Startup on dual-boot machines. Leaving an NTFS filesystem in Windows' hybrid-hibernated state and then accessing it from another OS is something I prefer to avoid entirely.

2. Use a stable kernel baseline

Fedora normally tracks newer kernels aggressively.

That is great for getting new hardware support quickly, but it also means that the kernel, Intel graphics, NVIDIA module, ACPI behavior, and suspend/resume code can all change independently.

For this workstation I use the unofficial 6.12 LTS kernel maintained in the kwizart/kernel-longterm-6.12 COPR.

The project is specifically intended to provide the Linux 6.12 long-term branch on Fedora and is useful for systems using external kernel modules such as NVIDIA.

Install it with:

sudo dnf copr enable kwizart/kernel-longterm-6.12

sudo dnf install \
    kernel-longterm \
    kernel-longterm-devel \
    kernel-longterm-modules-extra \
    kernel-longterm-core \
    kernel-longterm-modules \
    kernel-longterm-modules-core
Enter fullscreen mode Exit fullscreen mode

kernel-longterm-devel is important when using akmod-nvidia, because akmods needs matching kernel development files to build the NVIDIA kernel module.

Reboot:

sudo reboot
Enter fullscreen mode Exit fullscreen mode

Then verify:

uname -r
Enter fullscreen mode Exit fullscreen mode

You should see something from the 6.12.x series.

Check the currently configured default kernel:

sudo grubby --default-kernel
Enter fullscreen mode Exit fullscreen mode

Once I have verified that a kernel works correctly with the NVIDIA module, I prefer to keep that combination stable rather than changing both layers simultaneously.

3. Verify the NVIDIA driver before configuring hibernation

Before adding hibernation to the equation, make sure the GPU stack itself is healthy.

I use the stable/production NVIDIA branch packaged through RPM Fusion rather than NVIDIA's .run installer.

Check the loaded driver:

nvidia-smi
Enter fullscreen mode Exit fullscreen mode

Then compare the loaded kernel module with the installed userspace stack:

modinfo nvidia | grep '^version:'

cat /proc/driver/nvidia/version
Enter fullscreen mode Exit fullscreen mode

These versions should agree.

This may sound obvious, but it becomes important after updates: an updated userspace package combined with an older still-loaded kernel module can produce extremely confusing graphics and resume problems.

I cover that failure mode separately in Part 2.

4. Verify that the kernel actually supports hibernation

Do this before configuring swap or dracut.

cat /sys/power/state
Enter fullscreen mode Exit fullscreen mode

For hibernation, disk must be available:

freeze mem disk
Enter fullscreen mode Exit fullscreen mode

Then check:

cat /sys/power/disk
Enter fullscreen mode Exit fullscreen mode

On my machine it looks similar to:

[platform] shutdown reboot suspend test_resume
Enter fullscreen mode Exit fullscreen mode

The brackets indicate the currently selected hibernation mode.

If /sys/power/state does not contain:

disk
Enter fullscreen mode Exit fullscreen mode

stop here.

Adding more swap or changing GRUB will not solve a kernel-level hibernation restriction.

Also check Secure Boot:

mokutil --sb-state
Enter fullscreen mode Exit fullscreen mode

For this configuration:

SecureBoot disabled
Enter fullscreen mode Exit fullscreen mode

is expected.

5. Understand the swap requirement

Fedora Workstation normally uses zram for swap.

That is useful during normal operation, but zram lives in RAM. Once power disappears, its contents disappear too.

A hibernation image therefore needs persistent, disk-backed swap.

I use:

64 GB RAM
~74 GB disk-backed swap
Enter fullscreen mode Exit fullscreen mode

A swap device does not mathematically have to be larger than physical RAM in every possible workload because the kernel does not necessarily write every RAM page unchanged.

But for a workstation where hibernation should remain dependable even under heavy memory usage, I prefer not to depend on compression ratios or workload characteristics.

For 64 GB RAM, roughly 70–80 GB of persistent swap is a comfortable configuration.

6. Keep the swap inside LUKS

My Fedora installation uses a layout conceptually similar to:

NVMe
└── LUKS container
    └── LVM
        ├── root
        └── swap
Enter fullscreen mode Exit fullscreen mode

That has an important property:

RAM
 ↓
hibernation image
 ↓
swap LV
 ↓
LUKS
 ↓
physical SSD
Enter fullscreen mode Exit fullscreen mode

The hibernation image is therefore encrypted at rest.

Inspect the current layout:

lsblk -o NAME,TYPE,FSTYPE,SIZE,UUID,MOUNTPOINTS
Enter fullscreen mode Exit fullscreen mode

Also inspect LVM:

sudo pvs
sudo vgs
sudo lvs
Enter fullscreen mode Exit fullscreen mode

If you already have a sufficiently large disk-backed swap LV, do not recreate it.

Creating a dedicated swap LV

The following example assumes your LUKS-backed LVM volume group has enough free space.

Check first:

sudo vgs
Enter fullscreen mode Exit fullscreen mode

Then create the LV:

sudo lvcreate \
    -L 74G \
    -n hibernate_swap \
    <VG_NAME>
Enter fullscreen mode Exit fullscreen mode

Only on the newly created LV:

sudo mkswap /dev/<VG_NAME>/hibernate_swap
Enter fullscreen mode Exit fullscreen mode

Enable it:

sudo swapon /dev/<VG_NAME>/hibernate_swap
Enter fullscreen mode Exit fullscreen mode

Verify:

sudo swapon --show
Enter fullscreen mode Exit fullscreen mode

Fedora's zram swap may still appear here. That is fine.

What matters is that a persistent disk-backed swap device also exists.

7. Make the swap persistent

Get its UUID:

sudo blkid /dev/<VG_NAME>/hibernate_swap
Enter fullscreen mode Exit fullscreen mode

Example:

/dev/mapper/fedora-hibernate_swap:
UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
TYPE="swap"
Enter fullscreen mode Exit fullscreen mode

Add the UUID to /etc/fstab:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none swap defaults 0 0
Enter fullscreen mode Exit fullscreen mode

Then verify:

sudo swapoff /dev/<VG_NAME>/hibernate_swap
sudo swapon -a
sudo swapon --show
Enter fullscreen mode Exit fullscreen mode

Do not proceed until the disk-backed swap returns automatically.

8. Configure the resume device

Now the kernel must know where the hibernation image should be restored from.

For a dedicated swap partition or logical volume, this is straightforward:

resume=UUID=<SWAP_UUID>
Enter fullscreen mode Exit fullscreen mode

A dedicated block-device swap does not require resume_offset.

resume_offset is relevant to cases such as swapfiles, where the hibernation image lives at an offset inside another filesystem-backed block device.

systemd's hibernate-resume generator uses the resume= kernel parameter to select the resume device during early boot.

On Fedora I prefer grubby rather than manually rebuilding GRUB configuration.

Add the parameter to all installed kernels:

sudo grubby \
    --update-kernel=ALL \
    --args="resume=UUID=<SWAP_UUID>"
Enter fullscreen mode Exit fullscreen mode

Inspect the configuration:

sudo grubby --info=ALL | grep -E \
    '^(kernel|args)='
Enter fullscreen mode Exit fullscreen mode

Then reboot:

sudo reboot
Enter fullscreen mode Exit fullscreen mode

After boot:

cat /proc/cmdline
Enter fullscreen mode Exit fullscreen mode

You should see:

resume=UUID=<SWAP_UUID>
Enter fullscreen mode Exit fullscreen mode

A convenient check is:

tr ' ' '\n' < /proc/cmdline | grep '^resume='
Enter fullscreen mode Exit fullscreen mode

9. Make sure dracut contains resume support

This part turned out to be more important than I initially expected.

The kernel may know the swap UUID, but the initramfs must also contain the logic necessary to resume the system before normal userspace starts.

Fedora uses dracut to build its initramfs. Fedora's dracut package supports encrypted LUKS, LVM, and other device-mapper based root layouts.

I explicitly add the resume dracut module.

Create:

/etc/dracut.conf.d/99-resume.conf
Enter fullscreen mode Exit fullscreen mode

with:

add_dracutmodules+=" resume "
add_device+=" UUID=<SWAP_UUID> "
Enter fullscreen mode Exit fullscreen mode

Check that resume is not explicitly omitted

This deserves its own check.

Run:

grep -RniE \
    'resume|omit_dracutmodules' \
    /etc/dracut.conf \
    /etc/dracut.conf.d \
    2>/dev/null
Enter fullscreen mode Exit fullscreen mode

At one point my otherwise working hibernation setup stopped functioning because dracut reported:

Module 'resume' will not be installed,
because it's in the list to be omitted!
Enter fullscreen mode Exit fullscreen mode

If you find something like:

omit_dracutmodules+=" resume "
Enter fullscreen mode Exit fullscreen mode

remove resume from that configuration before continuing.

Dracut itself warns against manually omitting modules because removing an essential module can produce exactly this kind of failure.

10. Rebuild the initramfs

Rebuild all installed initramfs images:

sudo dracut --regenerate-all --force
Enter fullscreen mode Exit fullscreen mode

Or rebuild only the currently running kernel:

sudo dracut \
    --force \
    /boot/initramfs-$(uname -r).img \
    $(uname -r)
Enter fullscreen mode Exit fullscreen mode

Inspect the resulting initramfs:

sudo lsinitrd \
    /boot/initramfs-$(uname -r).img \
    | grep -i resume
Enter fullscreen mode Exit fullscreen mode

I prefer explicitly validating the image instead of assuming that because dracut exited successfully, the required resume path must be there.

11. NVIDIA power-management configuration

NVIDIA adds another stateful device to the suspend/hibernate path: GPU memory.

The NVIDIA driver can preserve GPU state across suspend and hibernation, but preserving all video-memory allocations requires additional integration when using the /proc/driver/nvidia/suspend mechanism.

NVIDIA documents dedicated systemd suspend, hibernate, and resume hooks for this purpose.

On my workstation I use:

NVreg_PreserveVideoMemoryAllocations=1
NVreg_TemporaryFilePath=/var/tmp
Enter fullscreen mode Exit fullscreen mode

Create:

/etc/modprobe.d/nvidia-power-management.conf
Enter fullscreen mode Exit fullscreen mode

with:

options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/tmp
Enter fullscreen mode Exit fullscreen mode

The filesystem behind /var/tmp must have enough free space to temporarily store the GPU allocations.

For an 8 GB RTX 4070 Laptop GPU, I make sure considerably more than 8 GB is available:

df -h /var/tmp
Enter fullscreen mode Exit fullscreen mode

Check the NVIDIA power-management units:

systemctl status \
    nvidia-suspend.service \
    nvidia-hibernate.service \
    nvidia-resume.service
Enter fullscreen mode Exit fullscreen mode

When using the full VRAM preservation mechanism, these units need to participate in the power-management sequence.

After changing module options:

sudo dracut --regenerate-all --force
sudo reboot
Enter fullscreen mode Exit fullscreen mode

Then verify the loaded parameters:

grep -E \
    'PreserveVideoMemoryAllocations|TemporaryFilePath' \
    /proc/driver/nvidia/params
Enter fullscreen mode Exit fullscreen mode

NVIDIA notes that insufficient or incomplete VRAM preservation can otherwise result in rendering corruption or application failures after a power-management cycle.

12. Validate the entire chain before the first hibernate

At this point I run a full sanity check.

Kernel 

cat /sys/power/state
Enter fullscreen mode Exit fullscreen mode

Expected:

freeze mem disk
Enter fullscreen mode Exit fullscreen mode

Hibernation mode 

cat /sys/power/disk
Enter fullscreen mode Exit fullscreen mode

Expected to contain usable modes rather than only:

[disabled]
Enter fullscreen mode Exit fullscreen mode

Persistent swap 

sudo swapon --show
Enter fullscreen mode Exit fullscreen mode

Confirm that the disk-backed swap is present and large enough.

Resume kernel parameter 

tr ' ' '\n' < /proc/cmdline | grep '^resume='
Enter fullscreen mode Exit fullscreen mode

Kernel resume device 

cat /sys/power/resume
Enter fullscreen mode Exit fullscreen mode

This normally contains the device's:

major:minor
Enter fullscreen mode Exit fullscreen mode

rather than:

0:0
Enter fullscreen mode Exit fullscreen mode

Compare it with:

lsblk -o NAME,MAJ:MIN,FSTYPE,SIZE
Enter fullscreen mode Exit fullscreen mode

initramfs 

sudo lsinitrd \
    /boot/initramfs-$(uname -r).img \
    | grep -i resume
Enter fullscreen mode Exit fullscreen mode

NVIDIA 

nvidia-smi

modinfo nvidia | grep '^version:'

cat /proc/driver/nvidia/version
Enter fullscreen mode Exit fullscreen mode

Once all of these agree, I consider the system ready for the first real test.

13. Test hibernation from the command line first

Do not start by debugging the GNOME power menu.

First test the mechanism directly:

sudo systemctl hibernate
Enter fullscreen mode Exit fullscreen mode

The sequence should look like this:

running Fedora
      ↓
systemd prepares userspace
      ↓
NVIDIA saves GPU state
      ↓
kernel writes RAM image to swap
      ↓
machine powers off
      ↓
power on
      ↓
firmware → bootloader → kernel
      ↓
LUKS unlock
      ↓
initramfs finds resume device
      ↓
kernel restores memory image
      ↓
existing Fedora session continues
Enter fullscreen mode Exit fullscreen mode

After resume, your applications and desktop session should be in the state they were in before hibernation.

14. Check the logs after resume

For a successful hibernation/resume cycle, inspect the current boot:

journalctl -b | grep -Ei \
    'hibernate|hibernation|resume|PM:'
Enter fullscreen mode Exit fullscreen mode

And kernel messages:

journalctl -b -k | grep -Ei \
    'hibernate|hibernation|resume|PM:'
Enter fullscreen mode Exit fullscreen mode

If hibernation failed and the machine performed a completely fresh boot instead of restoring the image, the previous boot becomes interesting:

journalctl -b -1
Enter fullscreen mode Exit fullscreen mode

That distinction matters.

A successful hibernation is conceptually a continuation of the previous running system, not simply a normal shutdown followed by a new login session.

15. What a healthy configuration looks like

My working baseline can be summarized as:

Secure Boot
    OFF

Kernel
    6.12 LTS

NVIDIA
    stable production branch
    matching userspace + kernel module

Storage
    LUKS
      └── LVM
           ├── root
           └── ~74 GB swap

Kernel command line
    resume=UUID=<swap UUID>

dracut
    resume module included

initramfs
    rebuilt and verified

NVIDIA PM
    VRAM preservation configured

/sys/power/state
    freeze mem disk

systemctl hibernate
    powers off

next boot
    restores previous session
Enter fullscreen mode Exit fullscreen mode

The important part is not any single command.

It is that every layer agrees about the same resume path.

16. Things I deliberately do not change once the system is stable

Power-management debugging gets difficult when several major components change at the same time.

On this machine I intentionally treat the following as a tested combination:

kernel
+
NVIDIA driver
+
initramfs
+
firmware
+
GNOME/Mutter
+
audio stack
Enter fullscreen mode Exit fullscreen mode

That does not mean I never update them.

It means I avoid blindly updating everything and then trying to determine which of five changed components caused a resume regression.

For example, after a kernel or NVIDIA update I verify:

uname -r
nvidia-smi
modinfo nvidia | grep '^version:'
Enter fullscreen mode Exit fullscreen mode

before trusting suspend or hibernate again.

If an update breaks the GPU module, Fedora's grubby makes it easy to keep or select a known-good kernel while investigating.

Hibernation is only half the story

Once the configuration above is correct, hibernation itself becomes surprisingly reliable.

Unfortunately, that does not mean the complete Linux desktop power-management stack will always behave.

During long-term use of Fedora 43 on this machine I encountered several completely separate problems:

  • GNOME entering suspend twice because of a gnome-settings-daemon regression;
  • GNOME Shell/Mutter resume regressions;
  • Bitwarden causing kernel hibernation to become unavailable;
  • NVIDIA userspace and kernel-module versions becoming mismatched after updates;
  • ALSA/UCM regressions and PipeWire xruns after long suspend/hibernate cycles.

Those problems are particularly confusing because they can make a perfectly valid hibernation setup look broken.

I will cover them separately in Part 2: Fedora Hibernation and Suspend Issues — GNOME, NVIDIA, Bitwarden and Audio.

Final thoughts

Hibernation on a modern Linux workstation is not really one feature.

It is a chain.

UEFI
 → kernel
 → encryption
 → swap
 → resume target
 → initramfs
 → systemd
 → GPU
 → desktop
Enter fullscreen mode Exit fullscreen mode

Trying random GRUB options rarely helps if you do not first determine which layer is failing.

The approach that worked best for me was to establish a deliberately boring baseline:

  • an LTS kernel,
  • a stable NVIDIA driver,
  • encrypted persistent swap,
  • an explicit resume target,
  • and an initramfs whose contents I actually verified.

Once that foundation works, bugs higher in the stack become much easier to identify.

And, as Part 2 will demonstrate, sometimes the component breaking hibernation turns out to be the last one you would expect.

This post was edited during 2 ballistic missile attack on Kyiv, during night onNov 7, 2026. Luckily, I am still alive.
russia IS A TERRORIST STATE.

Thank you for your time and hope it will be helpful.

Top comments (0)