[arch-projects] [mkinitcpio] [PATCH 2/2] resume: generate a udev rule for specifying device

Thomas Bächler thomas at archlinux.org
Tue Nov 26 04:44:48 EST 2013

Am 24.11.2013 03:01, schrieb Dave Reisner:
> This solves the problem of the major:minor of devices changing between
> hibernation. It also makes initialization lazy, as we no longer need to
> explicitly wait on the device to show up (this will be taken care of by
> udevadm settle).
> Note that this patch drops support for tux-on-ice. As upstream
> developerment of TOI seems stalled and forever relegated to being
> maintained out of tree, I'm okay with this.
> Signed-off-by: Dave Reisner <dreisner at archlinux.org>
> ---
> So, I tested this as far as ensuring that the udev rule is generated correctly
> and triggers, writing the correct values into /sys/power/resume, but I can't
> actually hibernate/resume my desktop to test this (mobo firmware bug).

Your firmware should not be involved at all in hibernation. As far as
your firmware is concerned, you shut down and reboot.

> If anyone who uses this hook wants to test this, please do and report back.

I feel this approach is extremely dangerous due to the fragile state of
file systems during hibernation.

Note that the file system must not change at all while the system is
hibernated. The kernel's internal state is saved in the hibernation
image - if the file system changed while the system was hibernated, the
on-disk and in-memory state will be inconsistent, almost guaranteeing
corruption (I have experienced this first-hand).

Now, your new approach does not preserve the ordering: Trying to resume
from a hibernation image MUST happen BEFORE any of the hibernated
system's mounted file systems are touched.

Now imagine the following situation: You have two hard drives, one
holding your root file system, the other holding your swap (and thus
hibernation image). Now imagine the following order of events:

* Linux loads, starts /init
* Udev is started
* Hard drive A is detected.
* fsck is started, repairs the "dirty" root file system (and changes
on-disk structures, clears the journal, ...)
* Hard drive B is detected -> udev start the resume procedure.

Now, you have a casual file system corruption. This should easily be
reproducible by putting your swap on a hard drive and the root file
system on SSD. To reproduce this more reliably, but the swap on USB instead.

This patch gets as many -1's from me as I can find. Hibernation is
dangerous for your data as it is, this patch plays russian data roulette.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20131126/72f3f77a/attachment.asc>

More information about the arch-projects mailing list