Package: linux-patch-tuxonice Version: 3.0.1+2.6.30-2 Severity: critical Justification: causes serious data loss
Hi it seems that tuxonice on resuming does not check if mounted partitions have been accessed since last hibernating. Thus people will suffer from data loss if they hibernate and, for example, boot another operating system, access partitions and resume the hibernated system afterwards. You could say that people should know that they should not access partitions which are in use by a hibernated system, but even if you are careful there is still a risk of loosing data, as the following example shows, where an unlucky interaction of patched kernel, unpatched kernel and grub corrupted my root partition. I have a self-compiled and tuxonice-patched kernel (2.6.30) installed which I usually run and I have a standard debian kernel installed without tuxonice. Now the following happened: 1. apt-get upgraded the package linux-image-2.6-686 and installed a new major kernel version (linux-image-2.6.32-trunk-686). The new kernel was added to the grub configuration and due to that my "default" setting in grub did not point on my self-compiled kernel any more, but it pointed on an unpatched kernel. 2. Some hours later I hibernated using tuxonice. 3. On the next day I accidently booted the unpatched kernel which had become default selection in grub. Thus my desktop was not resumed which didn't seem to be a problem. I just lost my open desktop windows. What I didn't realize at that time was the fact, that upon booting, linux didn't activate the swap partition, because there was still the tuxonice image in the swap and the unpatched kernel refused to activate the swap as it didn't look like a swap partition to the kernel. So the swap partition was left untouched. 4. On the next day I booted the tuxonice-patched kernel and it resumed the image that it found in the swap space. I didn't realize that fast enough and when my desktop reappeared I realized that something was wrong and I did a hard reboot, but at that time it was already too late. My system then booted into emergency shell and I had to run e2fsck manually. There were several files destroyed, distributed all over the filesystem. Fortunately I had a backup of my home and debsums helped me with the rest. I think tuxonice should somehow check if mounted partitions have been accessed inbetween, before resuming. If this is not possible then there should maybe be a init.d script which checks if the swap space could not be activated due to a tuxonice signature in swap and delete it. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-rf (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-patch-tuxonice depends on: ii bash 4.1-1 The GNU Bourne Again SHell ii dctrl-tools [grep-dctrl] 2.14 Command-line tools to process Debi ii patch 2.6-2 Apply a diff file to an original Versions of packages linux-patch-tuxonice recommends: ii hibernate 1.99-1.1 smartly puts your computer to slee ii linux-source-2.6.30 2.6.30-8squeeze1 Linux kernel source for version 2. Versions of packages linux-patch-tuxonice suggests: ii tuxonice-userui 1.0-1 user-space interfaces for TuxOnIce -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
