So I messed up and executed echo disk > /sys/power/state instead of echo mem > /sys/power/state accidentally. And then realized what I had just done.

Some details about the setup:

  • It's using LUKS encryption on the root partition
  • EFI stub boot loader (I can set kernel parameters with efibootmgr entries)
  • Swapfile is located on the Btrfs file system on the LUKS partition
  • Of which I don't have the swap file offset for... I hope I'm not screwed.

My custom initramfs init script doesn't have resume implemented yet. So I need to go into a bootable USB and somehow extract the kernel archive (initramfs is embedded in the kernel) and make changes to the init file, then compress it again. If that's even possible for the kernel executable. I probably can't recompile the kernel again unless I spend a lot of time getting kernel sources and recompiling it for my gentoo environment. But I might be able to as a last resort. So, 1. How could I edit vmlinuz (the kernel archive) with the updated init file?

After the LUKS partition is unlocked, how do I go about reaching this swap file? I don't have the offset for my swap file. I don't know now is Linus going to know where my swap file is. Is it as simple as "echo /dev/mapper/myrootfs > /sys/power/state"? It seemed to go fine doing the initial hibernation so Linux seemed to easily find out where my swap file was. Maybe it's the same for resuming? So, 2. How should I approach the swap file, I don't know it's offset. Will mounting as read only work then specify the swap file to /sys/power/state work or will that break my file system? (as the file system is technically "still mounted"). Maybe echo /dev/mapper/myrootfs to /sys/power/state like said earlier, but the point of specifying an offset is so that Linux knows where the swap file is. Which I don't have.

Edit: I didn't have any important stuff like documents unsaved or anything (all I had open was X, my WM and a terminal window). If I can boot normally (at that reverted state) and then discard that hibernation copy (like I said I didn't have unsaved documents or anything like that) that would be fine. Is that possible? Or is my file system in an unsafe state now and mounting it would only break it?

1 Answer 1


It's safe to boot if you don't care about the suspended session

Your filesystem won't be harmed if you boot and don't restore the suspended session. All the data needed to restore the session has been saved into the swapfile only. After saving the session your computer turns off normally so the filesystem is not 'still mounted'.

I've got a similar setup (using systemd). I reproduced your scenario to see what would happen by:

  1. Suspending my system to disk
  2. Removing resume=<device> resume_offset=999999 from the kernel command line in my bootloader

The system booted normally (with no resuming performed). My filesystem was healthy and swap was empty.

Recovering your suspended system

I'd do the following if to fix resume from hibernation

  1. Boot to some installation media
  2. Unlock and mount the system partition (and the one containing the swapfile)
  3. Find the swapfile's offset (see this ArchWiki article for Btrfs)
  4. Modify the bootloader's entry to specify resume device and offset
  5. Reboot the system normally

Note that it is not safe to resume if you've modified the filesystem since the suspension.

With a custom init script you'll need to modify the script within your initramfs. The easiest way to do so would be from to modify the script and recreate it from some installation media.
In your script you'll need to do something like

echo 99999 > /sys/power/resume_offset
echo /dev/mapper/myrootfs > /sys/power/resume

Modify and regenerate your initramfs from the installation medi

Take a look at what systemd does

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.