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

Andy Mindful — Sun, 08 Nov 2026 11:59:00 +0000

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

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

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

did not expose disk.

With it disabled:

freeze mem disk

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

Then reboot into UEFI and disable Secure Boot.

After confirming that Windows still boots normally:

Resume-BitLocker -MountPoint "C:"

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

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

Then verify:

uname -r

You should see something from the 6.12.x series.

Check the currently configured default kernel:

sudo grubby --default-kernel

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

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

modinfo nvidia | grep '^version:'

cat /proc/driver/nvidia/version

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

For hibernation, disk must be available:

freeze mem disk

Then check:

cat /sys/power/disk

On my machine it looks similar to:

[platform] shutdown reboot suspend test_resume

The brackets indicate the currently selected hibernation mode.

If /sys/power/state does not contain:

disk

stop here.

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

Also check Secure Boot:

mokutil --sb-state

For this configuration:

SecureBoot disabled

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

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

That has an important property:

RAM
 ↓
hibernation image
 ↓
swap LV
 ↓
LUKS
 ↓
physical SSD

The hibernation image is therefore encrypted at rest.

Inspect the current layout:

lsblk -o NAME,TYPE,FSTYPE,SIZE,UUID,MOUNTPOINTS

Also inspect LVM:

sudo pvs
sudo vgs
sudo lvs

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

Then create the LV:

sudo lvcreate \
    -L 74G \
    -n hibernate_swap \
    <VG_NAME>

Only on the newly created LV:

sudo mkswap /dev/<VG_NAME>/hibernate_swap

Enable it:

sudo swapon /dev/<VG_NAME>/hibernate_swap

Verify:

sudo swapon --show

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

Example:

/dev/mapper/fedora-hibernate_swap:
UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
TYPE="swap"

Add the UUID to /etc/fstab:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none swap defaults 0 0

Then verify:

sudo swapoff /dev/<VG_NAME>/hibernate_swap
sudo swapon -a
sudo swapon --show

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>

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>"

Inspect the configuration:

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

Then reboot:

sudo reboot

After boot:

cat /proc/cmdline

You should see:

resume=UUID=<SWAP_UUID>

A convenient check is:

tr ' ' '\n' < /proc/cmdline | grep '^resume='

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

with:

add_dracutmodules+=" resume "
add_device+=" UUID=<SWAP_UUID> "

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

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!

If you find something like:

omit_dracutmodules+=" resume "

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

Or rebuild only the currently running kernel:

sudo dracut \
    --force \
    /boot/initramfs-$(uname -r).img \
    $(uname -r)

Inspect the resulting initramfs:

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

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

Create:

/etc/modprobe.d/nvidia-power-management.conf

with:

options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/tmp

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

Check the NVIDIA power-management units:

systemctl status \
    nvidia-suspend.service \
    nvidia-hibernate.service \
    nvidia-resume.service

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

Then verify the loaded parameters:

grep -E \
    'PreserveVideoMemoryAllocations|TemporaryFilePath' \
    /proc/driver/nvidia/params

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

Expected:

freeze mem disk

Hibernation mode

cat /sys/power/disk

Expected to contain usable modes rather than only:

[disabled]

Persistent swap

sudo swapon --show

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

Resume kernel parameter

tr ' ' '\n' < /proc/cmdline | grep '^resume='

Kernel resume device

cat /sys/power/resume

This normally contains the device's:

major:minor

rather than:

0:0

Compare it with:

lsblk -o NAME,MAJ:MIN,FSTYPE,SIZE

initramfs

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

NVIDIA

nvidia-smi

modinfo nvidia | grep '^version:'

cat /proc/driver/nvidia/version

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

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

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:'

And kernel messages:

journalctl -b -k | grep -Ei \
    'hibernate|hibernation|resume|PM:'

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

journalctl -b -1

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

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

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:'

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

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.

DEV Community: Andy Mindful