linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Problem with hibernate partitions and encrypted volumes
@ 2014-02-25  3:27 Robert Hancock
  0 siblings, 0 replies; only message in thread
From: Robert Hancock @ 2014-02-25  3:27 UTC (permalink / raw)
  To: linux-kernel, pm list

A while ago I reported this Fedora bug:

https://bugzilla.redhat.com/show_bug.cgi?id=981841

and thought I would check on the kernel side about what the best way to 
handle the problem was.

Essentially the problem relates to the way in which the kernel stores 
the device that it uses to resume and hibernate to/from. During boot, 
dracut writes the device major/minor number of the swap partition to 
/sys/power/resume, which triggers the kernel to resume from disk if a 
valid resume image is present. If not, bootup continues normally, and 
the kernel has stashed away that major/minor pair as 
swsusp_resume_device. Later on, when you choose to hibernate the system 
and "disk" gets written to /sys/power/state, the kernel uses that device 
as the swap partition it will try to save the hibernate image to.

The problem comes in when the swap partition is on a LUKS encrypted 
volume - specifically, when there is more than one encrypted volume on 
the system. (In my case, the machine has separate encrypted /home and 
swap partitions.) Since the kernel stores the resume partition as a 
major/minor pair, it's sensitive to any change in the device ordering. 
It appears that at some point in the Fedora boot process, the device 
nodes for the encrypted volumes get torn down and re-created, and there 
is apparently no guarantee of the order in which this will occur. If the 
devices get recreated in the opposite order (for example if the swap 
partition was originally minor 1 and is now minor 2), the stored device 
ID will no longer refer to a swap partition, and the hibernate process 
discovers this and aborts.

It seems like all of this could be avoided if there was a way for 
userspace to set the device used to store the hibernate image before 
triggering hibernation. As far as I can see there is no way to change 
the device stored in swsusp_resume_device without writing to 
/sys/power/resume, which immediately tries to resume from it. That seems 
like quite a hack when one is trying to hibernate. It seems like the 
"set image device" and "resume" requests should be separated.

Any thoughts?

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2014-02-25  3:28 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-25  3:27 Problem with hibernate partitions and encrypted volumes Robert Hancock

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).