Handling hibernation swaps

From debian-derivatives:

> Raphael Hertzog wrote:
>> Paul Wise wrote:
>> If there is a way for the kernel/initrd to check if a particular swap
>> partition has valid hibernation data on it, then not formatting the
>> swap might be a good idea.
> Obviously the kernel does... the boot command-line is the same when you
> boot after hibernation than for a normal boot IIRC.

Sorry to respond to such an old mail, but this exact issue came up for us, and
I thought I'd contribute:

(1) Paul omitted one case: that where the user has a valid hibernation image
    in the swap partition, but doesn't care to keep it. In the extreme case,
    this could be a randomly generated valid image. You'd want to use the
    common swap partition here, so detecting a valid swapfile is only reason
    to warn the user, not necessarily refuse to format.

(2) In the SSD era, a proper mkswap(2) can be absolutely necessary for
    peak performance.

(3) The kernel command line is indeed the same in each case, as Raphael claims,
    *when hibernation is handled via initramfs*. In such cases, you'll find
    a RESUME parameter somewhere. Without an initramfs, it is necessary to
    pass the resume parameter on the kernel command line. Upshot: scanning for
    valid images among all possible locations is not what is typically done.

(4) It is possible to determine whether a swap device will be considered a
    hibernation image by some kernel by running that kernel's swap_type_of()
    code, as called by swsusp_check() and ultimately software_resume().

(4a) There is no assurance that the other kernels involved use the same image
     layout as you do, unless you've somehow ensure this.

(5) Use of swap *files* rather than swap *partitions* is probably a best
    practice when mixing multiple installs and hibernation.

(6) I'm not convinced that protecting a naive approach mixing swap partitions,
    hibernation, and multiple operating systems is any more important than
    "protecting" against trashing the hibernation image when an original,
    single operating system emerges from hibernation.

(6a) i.e., when a machine with a single operating system goes into hibernation,
     the user is responsible for ensuring that this hibernation partition is
     picked up and used on a subsequent boot. otherwise, the new boot will
     swap all over it.

(6b) i.e., use of hibernation as a checkpointing mechanism is beyond the basic
     goals of hibernation, and requires further user involvement.

(6c) I assert that the case Paul brought up reduces to use of hibernation
     as checkpointing. If we agree this is true, then (6) seems to hold in toto.

(6d) It is worth considering encrypted devices, both using known standards and
     unknown, in this context.