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).