Suppose I have two different Linux installations A and B, both using the same swap partition.

As I understand, running A or B will cause no problems with swap as only one of them is using it at a given time. However, if I boot A, hibernate, then boot B, swap is being used by both (A in a passive form, but data is there).

The question is: Will the hibernated system survive after this? If not, will the memory be corrupted or will A just be unable to resume, causing a regular boot?

Note: My main concert are live systems that detect and use available swap partitions on the hard drive. Will they destroy hibernated systems?

2 Answers 2


The question is: Will the hibernated system survive after this?

If system B uses the swap space, which you might as well presume it will, then I really doubt system A will be able to reboot from hibernation successfully, and the consequences may be bad if it does.

If not, will the memory be corrupted or will A just be unable to resume?

Although the kernel docs do contain:

 * BIG FAT WARNING *********************************************************
 * If you touch anything on disk between suspend and resume...
 *                              ...kiss your data goodbye.

This is meant to apply, I think, to the actual filesystem, since the same [src]/Documentation/power/swsusp.txt also notes:

The resume process checks for the presence of the resume device, if found, it then checks the contents for the hibernation image signature. If both are found, it resumes the hibernation image.

So, presuming that this signature is at the beginning of the swap device, and presuming that normal swap usage also starts at the beginning of the device, then normal swap usage will destroy the "hibernation image signature" and when system A boots, it will not find such a signature and won't resume from hibernation, it will just start fresh.

But while those presumptions seem reasonable, without any promise from the people who implemented the system, it is impossible to say they are completely sound -- my advice is you may be making a serious gamble by doing this.

If you are using hibernation and don't already have such an option in your bootloader menu, by the way, it is a good idea to have one which contains noresume on the kernel line so you can choose to skip resuming from hibernation. As far as I am aware, there is unfortunately no such kernel line parameter to disable the use of swap, e.g. for system B when you know system A used the swap for hibernation.

  • If system B uses the swap space, then it will overwrite the hibernated image from system A. Apr 7, 2014 at 18:20
  • @Gilles I would assume that also. My point is I can also come up with some (perhaps imaginative, but not infeasible) scenarios in which the "hibernation signature" is not corrupted, but significant parts of the image are. This would mean you'd have some "undefined behaviour" as a result, lol. Unless you have references which state unequivocally this is ok, I think it not a good practice to condone (even if you might be willing to chance it yourself).
    – goldilocks
    Apr 7, 2014 at 18:57

The first system stores its memory in swap, so if you try to boot the second system that also uses the same swap, then one of two things will happen: either the second system will try to resume using the first system's data, and this will crash and burn, or it will erase the first system's memory so it can not be resumed.

As a general rule you should never boot into another OS while one is hibernated. If the second tries to mount the same partition that the first had mounted, it will corrupt the filesystem since the second OS has no idea what data the first may still have cached, and the first has no idea what the second changed while it was hibernated.

  • The hibernation image contains an indication of the exact kernel version. Unless both installations use the same kernel, the second one will detect a version mismatch and will start afresh and overwrite the hibernated image. @Darkhogg Apr 7, 2014 at 18:19

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.