Handling hibernation swaps
> 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.