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

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 \ Only on the newly created LV: sudo mkswap /dev//hibernate_swap Enable it: sudo swapon /dev//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//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//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= 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=" 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= 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= " 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= 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.