linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Hancock <hancockrwd@gmail.com>
To: linux-kernel <linux-kernel@vger.kernel.org>,
	pm list <linux-pm@vger.kernel.org>
Subject: Problem with hibernate partitions and encrypted volumes
Date: Mon, 24 Feb 2014 21:27:57 -0600	[thread overview]
Message-ID: <530C0DBD.6060502@gmail.com> (raw)

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?

                 reply	other threads:[~2014-02-25  3:28 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=530C0DBD.6060502@gmail.com \
    --to=hancockrwd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).