I'm leaning towards this bug being in the uswsusp package. I see a few big problems here:
After installing uswsusp in its default configuration on a system with LVM swap, a user who hibernates their system or relies on the hybrid suspend for longer than the battery lasts will lose data. A fresh install of uswsusp on wheezy auto-populates the resume_device value in etc/uswsusp.conf and debconf based on /proc/swaps, which uses the "/dev/dm-NN" device node rather than the /dev/mapper/name (better) or uuid (probably best). The /dev/dm-NN node might point at something else across reboots. If s2disk doesn't sanity check the partition betfore writing to it, it could potentially scribble on the wrong partition. Reordering of devices could on reboot could allow resuming the system with the wrong suspend image, resulting in filesystem corruption. Due to the problems with the swap device being unavailable when the initrd runs scripts/local-premount/uswsusp, the likelyhood of an unused suspend image laying around is higher than normal. When building the initramfs, /usr/share/initramfs-tools/hooks/uswsusp sets $RES_DEV based on the value in /etc/uswsusp.conf, but that variable is not used anywhere by the process that determines which logical volumes to make available at early boot time. When scripts/local-premount/uswsusp runs /sbin/resume, the block device containing the suspend image doesn't exist yet. Setting $RESUME somewhere in /etc/initramfs-tools/conf.d/ will get things working, as will setting "resume=" on the kernel command line, but this whole thing should be automatic. -- Brian Ristuccia br...@ristuccia.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
