I recently ran into a problem with suspend to disk on Fedora 19, which I
reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=981841
In this case swap and /home are encrypted volumes. Essentially (from
what I understand, correct me if I'm wrong) what happens is that when
dracut boots up, unlocks the encrypted swap and writes the major/minor
number of the swap partition to /sys/power/resume to try to resume from
it, and fails as there's no hibernate image present, the kernel still
stashes away the major/minor number of the device into
swsusp_resume_device (see resume_store in kernel/power/hibernate.c). For
whatever reason those dm-crypt mappings get torn down after dracut
finishes and recreated afterwards. As it turned out, because of the
order of the LUKS entries on the kernel command line versus the order of
the lines in /etc/fstab, the mappings were being recreated in the
opposite order during the main boot sequence. This resulted in that
stored major/minor device in swsusp_resume_device now pointing at the
/home partition instead of the swap partition. When you go to hibernate,
it fails as obviously that device isn't a swap partition.
It seems to me that it's not a great idea to stash away major/minor
numbers at attempted resume and try to use them later on. There's no
guarantee that they will still point at the same device or even exist at
all. It appears that if the resume device was never explicitly set at
hibernate time, then the kernel will just pick a usable swap partition
to hibernate to, but once userspace has set a resume device, there's no
way to get the kernel to forget about that device and just auto-detect
at hibernate time again. And if that device no longer exists or isn't a
swap device anymore, it seems like you're pretty much screwed.
Any thoughts?
