Suspend-to-disk issue with identifying swap partition

From: Robert Hancock
Date: Wed Jul 10 2013 - 00:15:45 EST


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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/