I have computer with battery power supply that allows running the computer for approximately one minute after power loss. I want to trigger suspend-to-disk immediately after power loss so it can be resumed later. The initrd (default Devuan initrd) looks for suspend signature in the swap partition and resumes from it when the signature is found. I am not sure what happens when power is completely interrupted while writing data to the swap partition. That could happen when the battery fails or the system hangs while suspending. Will the system resume from the corrupted swap partition or it will just ignore the swap partition? I consider the second option better – it is better to have incorrectly unmounted filesystem than corrupted system state.

Is the signature written to the swap partition after or before the other data? Does it use checksums?

  • Part of the question is whether the suspend procedure is careful to make sure the "suspend signature" doesn't commit to disk before any of the writes of the suspend data. Hardware can do this, e.g. by making sure to flush the disk's internal write cache before the signature write, or a write barrier, the same kind of write ordering that journaling FSes rely on. Feb 22, 2021 at 11:03
  • (Or at least this would be the question if not for Chris's point that the next boot knows whether it's booting from a previous hibernation or not. Checks like that would seem to rule out hibernating Linux, booting another partition to e.g. play video games, then resuming Linux. IIRC, years ago Linux was more willing to resume without needing a special BIOS state.) Feb 22, 2021 at 11:06
  • I expect that if the swap partition is corrupted and used, there's a very high chance the computer will just crash completely, rather than silently corrupting stuff.
    – user253751
    Feb 22, 2021 at 12:48
  • 1
    @PeterCordes Sorry, my answer was a bit unclear about the implications of S4/S5. In the case where suspension goes to S5 (which should be the case on most modern platforms), it's generally possible to go into another operating system and later resume Linux. Hopefully my update makes that clearer.
    – Chris Down
    Feb 22, 2021 at 13:11
  • 1
    Hibernation has long been used as a last ditch attempt to save the state of the OS when a laptop battery is nearly empty. There's a non-negligible chance of the battery running out during the process. If this tended to cause system corruption, it would be all over the news.
    – TooTea
    Feb 22, 2021 at 14:49

1 Answer 1


If power is lost prior to explicitly entering S4 or S5 state (hereafter just referred to as "hibernation state" for simplicity), then the partially filled data in the swap partition will be ignored completely, because there's no hibernation state persisted. Swap partitions and files are also volatile, and the data in it will be ignored after a reboot without hibernation state.

In the kernel, restoration from hibernation is requested by the configured platform_hibernation_ops->leave, which is only called on resumption from hibernation state. For example, on most modern platforms where S5 is supported, we configure a reboot notifier.

Losing power prior to hibernation state being entered (and thus the hibernation file being completely written) won't have configured any hibernation to resume from, so there's no chance it will try to thaw using the partially-filled swap space. As such, you don't have to worry about the kernel trying to restore from a partially complete hibernation.

  • Linux hibernation to swap doesn't use S4 state. Feb 22, 2021 at 11:24
  • 1
    @SimonRichter I don't know why you think that, but yes, we do: github.com/torvalds/linux/blob/…. We'll also make use of S5 if it's available on the platform. If that's what you're referring to, sure, I can write S4/S5 everywhere, but that seemed fairly obvious.
    – Chris Down
    Feb 22, 2021 at 12:16
  • (It should be noted that really all kinds of states could be eventually used depending on the value of /sys/power/disk: see hibernation_mode in kernel/power/hibernate.c.)
    – Chris Down
    Feb 22, 2021 at 12:38
  • Eh? Wasn't S4 the state where the firmware is supposed to write out the image to disk and restore it ( presumably to some vendor specific hidden partition on the disk ), rather than the kernel? And no systems actually implemented it, which is why the kernel swsuspend handles it by saving it to the swap partition.
    – psusi
    Feb 22, 2021 at 16:13
  • @psusi It sounds like you're thinking of S4BIOS, not S4 (which uses hibernation state provided by the OS, not the firmware).
    – Chris Down
    Feb 22, 2021 at 16:43

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.