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