TuxOnIce FAQ Compiled by Bernard Blackham Gathered here is a collection of frequently asked questions about Software Suspend under Linux. It began life as a compilation of Flo- rent Chabaud's FAQ page and Bernard's mini-FAQ. The SGML source file is here . Please send any additions/corrections to this FAQ to me . ______________________________________________________________________ Table of Contents 1. Downloading TuxOnIce 1.1 How do I get the latest beta TuxOnIce? 1.2 How do I get the latest stable TuxOnIce? 1.3 What kernel do I need for the latest TuxOnIce? 1.4 How can I tell what version of TuxOnIce my distro's stock kernel came with? 2. Patching the kernel sources 3. Configure/compile problems 4. Compatibility issues 4.1 Filesystems. 4.2 Does SCSI support work? 4.3 Can TuxOnIce be compiled as modules? 4.4 nVidia video cards 4.5 nVidia GeForce4 card: black screen after resuming, amongst other symptoms 4.6 3D: Hibernation occurs correctly, but when I resume my Xserver has lost 3D acceleration. 4.7 PCMCIA: It hangs upon resume when restarting pcmcia! 4.8 ATI Radeon and DRI support - after resuming X becomes really sluggish 4.9 USB issues 5. Using TuxOnIce 5.1 TuxOnIce doesn't seem to do anything (or: I upgraded to the latest TuxOnIce and my machine no longer suspends! Instead, it shuts down all drivers, etc and then starts resuming.) 5.2 It doesn't power off, but hangs forever. 5.3 It resumes but hangs. I can't boot any more. Or, my machine reboots forever. 5.4 Suspending and resuming takes ages, what can I do? 5.5 Can I switch from Windows to Linux using TuxOnIce? 5.6 Can I change removable devices while suspended? 5.7 Suspension seems to occur correctly, but when I resume the suspend signature is not found. 5.8 After resume, why is my clock at the time of suspension? 5.9 How can I patch TuxOnIce to have a script launched on resume? 5.10 Suspension seems to occur correctly, but when I resume mouse and keyboard are frozen. 5.11 It fails to suspend with a message "not enough pages" 5.12 How can I get Bootsplash to play with Software suspend nicely? 5.13 Resuming complains about a version mismatch. 5.13.1 WARNING! Scenarios that can lead to data loss or corruption: 5.13.1.1 Scenario 1 - a second kernel recognises the suspend image 5.13.1.2 Scenario 2 - a second kernel does not recognise the suspend image 5.14 Is there any way to convince TuxOnIce to free things like disk caches and buffers but nothing else? 5.15 Freezer debugging: It hangs at 'Waiting for activity to finish' or 'Syncing remaining I/O'. 5.16 I've suspended and resumed and now I can't open new X applications and my /tmp directory is empty (on Debian) 5.17 On resume, you get a "BIG FAT WARNING!! Failed to translate the device name into a device id." 5.18 My system hibernates but doesn't even try to resume. 5.19 System hangs on booting a TuxOnIce kernel (2.6) 5.20 It suspends twice every time I hit the power button! 5.21 It hangs when "Copying original kernel back" 5.22 It hangs when "Reading caches" and I have a Toshiba laptop 5.23 Why is having a filesystem mounted at resume-time dangerous? 5.24 UserUI: I get "FBIOSPLASH_SETSTATE failed: error code 22" when using the suspend2ui_fbsplash 5.25 When suspending it fails with "Failed to initialise the compression transform" 6. Modular TuxOnIce 6.1 I get messages about the size of struct module not agreeing when the initrd tries to insert my suspend modules. 6.2 The modules are installed fine but the swapwriter complains about not being able to access the suspend device. 6.3 How do I update my running kernel modules without rebooting into a new kernel? 6.4 How can I update my initrd (initramfs) on Fedora? 6.5 How can I update my initrd on Debian? 7. Miscellaneous 7.1 What's left to do? 7.2 TuxOnIce seems nice, but can I use it for doing snapshots? 7.3 I can't capture the oops easily, what should I do? ______________________________________________________________________ 1. Downloading TuxOnIce 1.1. How do I get the latest beta TuxOnIce? Visit the Download page . Under the Development Patches package, grab the latest full tarball (called tuxonice-XXX-for-YYY.patch.bz2) for the releveant kernel. 1.2. How do I get the latest stable TuxOnIce? Visit the Download page . Under the Stable Patches package, grab the latest core patch and latest version-specific patch for your kernel version. 1.3. What kernel do I need for the latest TuxOnIce? 2.6 kernels come with their own version of Software Suspend (referred to on the mailing lists as swsusp). Generally speaking, more people have had success with TuxOnIce than the stock kernel version in 2.6. 1.4. How can I tell what version of TuxOnIce my distro's stock kernel came with? Most distributions don't include TuxOnIce in their stock kernels, but there are usually alternate sources from which you can get prebuilt kernels for your distribution. To find out what version of TuxOnIce you're running, run dmesg after boot, and search for any messages containing `TuxOnIce' or 'Suspend2' (the old name). There should be a version number listed. 2. Patching the kernel sources No FAQs presently. 3. Configure/compile problems No FAQs presently. 4. Compatibility issues 4.1. Filesystems. Ext3 is our favourite filesystem. It seems to be the most reliable of all the Linux filesystems, and copes just fine with suspending and then not resuming (which often happened in the past while Nigel was developing the code intensively). Other filesystems have been tested and do work, but ext3 is our fs of choice. 4.2. Does SCSI support work? SCSI support used to be nonexistant, but should be fine in recent kernels. 4.3. Can TuxOnIce be compiled as modules? Yes and no. Between versions 2.0.0.102 and 2.1.8.5, modular TuxOnIce was supported. It was dropped however in 2.1.8.6 to aid the efforts to get it merged into the kernel. (Lots of kernel folk weren't keen on what was modular TuxOnIce entailed). It has since been readded, but in such a way that it's easier to remove if we do ever get the code merged. 4.4. nVidia video cards (See also the next 2 FAQs). Many people have had success getting TuxOnIce to work with nVidia's 4496 driver on 2.4.x kernels (downloadable from http://www.nvidia.com/object/linux_display_archive.html ), and more recently, the 6629 driver on 2.6 kernels. agpgart must be removed from the kernel (either disable the module loading, or don't compile it in the first place). Update: See these release notes for nVidia's driver . 4.5. nVidia GeForce4 card: black screen after resuming, amongst other symptoms Upgrading to the latest nVidia driver (6629 confirmed working), disabling agpgart in the kernel, and setting "SwitchToTextMode no" and "UseDummyXServer no" in hibernate.conf should resolve this problem. 4.6. 3D: Hibernation occurs correctly, but when I resume my Xserver has lost 3D acceleration. This seems to happen for some hardware configurations under certain versions of XFree86 and Xorg (notably Radeons and Xorg 6.8.0). Launching a fake xserver just after resume may solve the problem. This can be done by adding xinit /bin/false -- :1 at the end of resume script. If you use the hibernate script, try the UseDummyXServer option (formerly known as nVidiaHack) in hiber- nate.conf. 4.7. PCMCIA: It hangs upon resume when restarting pcmcia! This has been reported on some hardware when using the kernel pcmcia support (yenta_socket). A workaround is to use pcmcia_cs support instead. Disable all PCMCIA kernel stuff and compile the pcmcia_cs package instead. Use PCIC=i82365 (less likely PCIC=tcic) option instead of yenta. 4.8. ATI Radeon and DRI support - after resuming X becomes really sluggish Xorg 6.7 works out of the box, as does the Xorg 6.8.x CVS branch. Xorg 6.8 requires the the UseDummyXServer option (formerly known as the nVidiaHack) in hibernate.conf to solve this problem. (at least it has worked for several people). More recent versions should work fine. 4.9. USB issues Some machines have issues with USB and TuxOnIce. The safest solution is to compile all your USB drivers in as modules, and unload them prior to suspending. 5. Using TuxOnIce 5.1. TuxOnIce doesn't seem to do anything (or: I upgraded to the lat- est TuxOnIce and my machine no longer suspends! Instead, it shuts down all drivers, etc and then starts resuming.) Suspend2/TuxOnIce's kernel interface has been through numerous modifications. We recommend using the hibernate script (also available from tuxonice.net). If you ensure you have the latest version of that, things should start working again (assuming Nigel just made another modification in this area). And if you are still having little or no success... o Check you have a resume=swap:/dev/hdXX option on your kernel commandline in your bootloader (eg, LILO or GRUB). o Grep through dmesg for 'Suspend2' or 'TuxOnIce' to see if it is giving any error messages on boot. o Check that in your .config you have the following lines: CONFIG_PM=y CONFIG_SUSPEND2=y (or CONFIG_TOI* after 2.2.10.2) CONFIG_SUSPEND2_SWAP=y (TOI_SWAP) ... CONFIG_CRYPTO_LZF=y o Did you really patch your kernel source? bzcat /path/to/tuxonice-2.x.y-for-2.6.z.patch.bz2 | patch -p1 -b should not return any failures. o Did you run make dep after patching? (2.4 only) o Are you really booting your freshly-compiled kernel? Run uname -a and check the timestamp - it should match the time of compilation. o To be absolutely certain there's nothing stale hanging about: SAVE your .config somewhere outside the kernel tree, run make mrproper, copy the .config back and then run make oldconfig dep bzImage modules. 5.2. It doesn't power off, but hangs forever. If you don't have ACPI or APM enabled in your kernel, TuxOnIce can't tell the hardware to power off, but if you reach a screen reading Ready to power down the suspend is complete and you can manually power off. 5.3. It resumes but hangs. I can't boot any more. Or, my machine reboots forever. You have to tell kernel to ignore the resume partition using the noresume option. On the lilo prompt, type something like "linux noresume". You may find useful to have one of your lilo choices launch your kernel with the noresume option. You now have to figure out why it didn't work ;-) See the Troubleshooting section of the HOWTO. 5.4. Suspending and resuming takes ages, what can I do? Using the suspend script, most of the delay is due to the necessity of stopping drivers before suspending and restarting them after resume. Suspending will never be as fast as you imagine it, at least as long as hardware drivers will not correctly handle suspending events. If the delay is in writing to disk, then you may want to play with the image_size_limit option in /sys/power/suspend2/. By setting a maximum image size, TuxOnIce will try and free as much memory as possible to achieve this (or failing that, flushing to disk) which will speed up suspend and resume on machines with slow disk IO. The only downfall is that your machine might not be as responsive on resume until buffers and caches are restored. If you are feeling daring, you can write your own customised suspend script, which does the minimum required for your machine. Some machines can suspend instantly simply by echo > /sys/power/suspend2/do_suspend. Others need a bit more of a hand - the big offenders are generally sound cards, network cards, PCMCIA and USB. 5.5. Can I switch from Windows to Linux using TuxOnIce? Yes, but the result is guaranteed only if the linux and windows partitions are totally independant. If for instance you use a FAT partition to share data between the two operating systems, you must unmount the partition before suspending. Otherwise, modification of data under Windows may be lost when resuming Linux. Conversely, modification of data under Linux will be lost if Windows 2000's own software suspension feature is used. Doug has posted the following message on the TuxOnIce mailing list concerning unmounting of drives in XP (not verified): > It is posible, there is iirc something in disk manager about this, I > will pay about with my win2k box and see if I can find it, but I have > definatly seen something about it. > > http://support.microsoft.com/default.aspx?scid=KB;EN-US;q314449& > might be the right sort of area > > -- > Tim Fletcher Actually that link looks dead on. Run mountvol from the command line with no parameters and you get a list of volume IDs (hideously long strings) and locations where they are mounted and details on syntax for how to mount and unmount drives. I've attached the screen output below. To automate it just go to http://www.budja.com/shutdown/ to get a simple little command-line program for hibernating and then write yourself a little .bat file to put it all together. Below is one I wrote but you'll need to run mountvol to get the right volume ID to put in here first before using it and put the right path in for the shutdown command. Of course I don't know yet what exactly "unmounting" means here. Does it really synchronize the disk or whatever is needed? I'll let ya know how the actual results are when using this to suspend in and out of windows and linux a few times. Next I'll try to get my "Easy Acess Buttons" programmed and maybe I'll even be able to reprogram the power button. If not it's not so bad to have to click a link somewhere to hibernate. Oh yeah... might as well add the A drive to this procedure... I doubt it matters though seeing as how you can pull idle floppy's out of windows without causing any harm anyway. 5.6. Can I change removable devices while suspended? This can be done provided you stop the corresponding drivers before suspending. For this reason, it seems better to stop USB, PCMCIA and IrDA before suspending and start the services back on resume. Good precaution is also to unmount the floppy drive. 5.7. Suspension seems to occur correctly, but when I resume the sus- pend signature is not found. Double check that you have correctly set a resume=swap:/dev/hdX option and that you have updated your lilo or grub configuration. Also check that you don't have an unwanted noresume option. If all this is OK than perhaps you have one of those disks with a flaky hardware cache. Try to use hdparm -W 0 /dev/hdX before suspending. This should disable hardware cache. Please report if you encounter this bug since it is supposed to be fixed since 2.4.18-beta8. 5.8. After resume, why is my clock at the time of suspension? The system time is stored in a part of memory that is saved during suspension. One needs to reset the clock using hwclock upon resume, since reading the CMOS is the only way for the system to know the real time. Use the hibernate script in order to do that automatically. This should also be done for you in recent 2.6 kernels. 5.9. How can I patch TuxOnIce to have a script launched on resume? See the hibernate script documentation. 5.10. Suspension seems to occur correctly, but when I resume mouse and keyboard are frozen. This seems to happen for some hardware configurations. We haven't found a proper way to fix that for the moment. Sometimes, it seems that stopping gpm before suspending and restarting it upon resume can help. In other cases, just stopping gpm and never restarting it is even better. 5.11. It fails to suspend with a message "not enough pages" The amount of memory needed depends on a lot of things. For the average user, sizeof(RAM)x2 is ample for the swap partition used by TuxOnIce. With compression, you should usually be able to get away with 1/2 the amount of RAM you have. If you're using the expected compression ratio, be careful not to set it too optimisticly. 5.12. How can I get Bootsplash to play with Software suspend nicely? Bootsplash is no longer supported with TuxOnIce. The code base wasn't easy to work with, and better alternatives emerged - (see UserUI ). The following exists for historical purposes only... Documentation contributed by Alessandro Barbosa (barbosa_alessandro at hotmail dot com): Bootsplash and Suspend2 on Fedora Core 2 Or the following, thanks to Markus Gaugusch and Nigel Cunningham: Bootsplash with software suspend still seems somewhat voodoo-ish, but hopefully the steps listed here will point you in the right direction. 1. Patch your kernel with the official bootsplash patch from www.bootsplash.org and read the documentation with it. Configure your kernel with bootsplash /proc support. 2. Install the splash utilities from bootsplash.org and a theme. 3. If you are using a version 1 or 2 bootsplash image, you will need to patch software suspend with the bootsplash-option patch in the Suspend2 package and recompile. With a version 3 bootsplash image, this is not neccesary. 4. On suspend, execute: /path/to/splash -s -u 62 /etc/bootsplash/themes/.../config/bootsplash-1024x768.cfg If you have a version 1 or 2 image, echo 424 582 506 30 15 > /proc/sys/kernel/splash_progress. These numbers are x-coordinate, y-coordinate, width, height and RGB colour (24-bit). This puts the splash screen on VT 63 (counting from 0), puts a black progress box roughly down the bottom. 5. Suspend. 6. On resume, execute splash -s -u 62 to clear the bootsplash again. 7. Possibly change VTs back to your original one. 5.13. Resuming complains about a version mismatch. The noresume kernel command line option discards the suspend image and restores the swap signature. When using the noresume option, the suspended kernel state and filesystem state is lost. When using a journaling filesystem, no filesystem data is lost. 5.13.1. WARNING! Scenarios that can lead to data loss or corruption: This may occur after suspending with a TuxOnIce-enabled kernel, then booting a different kernel. 5.13.1.1. Scenario 1 - a second kernel recognises the suspend image The version mismatch is caused by attempting to resume a kernel whose header does not match the header of the suspended kernel in the suspend image. For example, you suspended a kernel, and recompiled it, or you suspended one kernel and attempted to resume another one which recognizes the suspend image. In this case, put noresume on the command line for this boot. Should you forget, you will get a version mismatch message: SHIFT to reboot, CONTROL to continue - push shift and either select the correct kernel or use the noresume option to boot. Any difference between resumed and suspended kernels will corrupt/crash the system on forcing resume with CONTROL and possible cause filesystem damage as well. 5.13.1.2. Scenario 2 - a second kernel does not recognise the suspend image This is described in detail in the HOWTO (Avoiding data loss) . 5.14. Is there any way to convince TuxOnIce to free things like disk caches and buffers but nothing else? Yes. Set the image_size_limit option to -2. This will get TuxOnIce to do the equivalent to echo 1 > /proc/sys/vm/drop_caches while preparing the image. If you set the image_size_limit option to a positive value, TuxOnIce will attempt to free memory until the image size is less that the value in megabytes. Since disk caches are the easiest thing to free, the Linux VM will free it first. If you leave the value of image_size_limit at zero, it will only free as much memory as it needs to be able to suspend. If you are using the hibernate script, you can add the line ImageSizeLimit nocache to adjust the image_size_limit to approximate dropping caches and buffers. 5.15. Freezer debugging: It hangs at 'Waiting for activity to finish' or 'Syncing remaining I/O'. 1. Compile in debugging support if you haven't already. You may also want to increase the size of the message buffer: o For 2.4, edit kernel/printk.c. Change 16384 on line 41 to a higher power of two, say 1048576 o For 2.6, change the kernel log buffer size while choosing your compile options. It's under General Setup. 2. Set your debugging options as follows: o echo 1 > /sys/power/suspend2/user_interface/enable_escape - ensures you can press escape to cancel the suspend when it hangs o echo 1 > /sys/power/suspend2/user_interface/log_everything - tells TuxOnIce to record all it's about to display o echo 4 > /sys/power/suspend2/user_interface/default_console_level - tell it to display medium level debugging o echo 2 > /sys/power/suspend2/user_interface/debug_sections - tell it to display messages about the freezer 3. Tell it to try to suspend: echo > /sys/power/suspend2/do_suspend 4. When it hangs (assuming it does), press escape. It should print a lot of information and then return you to the command prompt. 5. Look in /var/log/messages. If the output does not contain the names of procedures, but instead lots of hexadecimal numbers, run the output through ksymoops. (See Documentation/oops-tracing in the kernel tree for more help here). 6. Send your output directly to Nigel, who will usually get back to you pretty quickly. Don't send all of the output to the list, please. 5.16. I've suspended and resumed and now I can't open new X applica- tions and my /tmp directory is empty (on Debian) A recent version of the initscripts package decided to blow away temporary directories when calling mountnfs.sh (See Bug #227112 ). The simple solution is to remove mountnfs.sh from your SWSUSP_STOP_SERVICES_BEFORE_SUSPEND in /etc/suspend.conf and add your extra NFS mounts into SWSUSP_UMOUNTS. Alternately, upgrade to the new hibernate script which does not call the init script in question. 5.17. On resume, you get a "BIG FAT WARNING!! Failed to translate the device name into a device id." This can happen for several reasons: o A misspelt resume= option on your kernel command line. o You are using an initrd, and IDE support is built as modules and the modules are not loaded yet. Load the IDE modules before calling the resume process in the initrd. o You are using an initrd, and it does not contain a /sys/ directory. 5.18. My system hibernates but doesn't even try to resume. If you're using an initrd or initramfs, you _MUST_ have a line in it telling TuxOnIce when to try to resume. This needs to be done before mounting any filesystems that were mounted when you hibernated, but after setting up access to anything TuxOnIce will need in order to resume (lmsetup etc). Note that if you hibernated to a swap file or ordinary file, you still don't need to mount the filesystem. Please also note that in the case of swap storage, every swap device needs to be accessible. Your image could have been stored on any combination of the devices that were swapon'd when you hibernated (which ones depends on a combination of what swap was in use, swap priorities assigned at swapon time and the amount of data written to disk). 5.19. System hangs on booting a TuxOnIce kernel (2.6) If CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled, you may get a hang on boot just after: TuxOnIce 2.2.10.2, with support for usm, compression, swap storage, file storage, userui. TuxOnIce: Normal swapspace found. Disabling CONFIG_CC_OPTIMIZE_FOR_SIZE appears to resolve the issue. Thanks to Michael Schneider for recognising this problem and solution! 5.20. It suspends twice every time I hit the power button! Your power button is probably sending two events every time you push it (sometimes one for depressing it, one for releasing it, sometimes just two events). You can tell acpid only to react to one event my editing your /etc/acpi/events/powerbtn file to contain "event=button[ /]power.*[02468ace]$" instead of the default event= line. This tells it to only respond to every second power button event. 5.21. It hangs when "Copying original kernel back" See the HOWTO . 5.22. It hangs when "Reading caches" and I have a Toshiba laptop This should be fixed since Suspend2 2.1.8.12. 5.23. Why is having a filesystem mounted at resume-time dangerous? The saved image of your kernel is intimately linked with the state of the filesystems that were mounted when you suspended. The kernel expects that it will be the only thing that can modify the filesystem whilst it is mounted. If between suspending and resuming your machine you mount a filesystem that was mounted in the suspended image, you will change its internal state (even if you don't modify any files). In particular, simply mounting a journalled filesystem read-only will replay the filesystem's journal, causing the state of the filesystem to be inconsistent with what the suspended image thinks it is. If a filesystem has been modified in the slightest, then resuming your suspended kernel will most likely cause corruption of the filesystem. This commonly occurs when people mount their root fs in their initrd, which is why the sanity check for mounted filesystems is there. In short, don't mount or touch filesystems that are mounted in the suspend image before resuming. A couple of people have lost their data this way. 5.24. UserUI: I get "FBIOSPLASH_SETSTATE failed: error code 22" when using the suspend2ui_fbsplash This just means you haven't patched your kernel with fbsplash, which is not required anyway. (If you do patch your kernel, you can also get prettier verbose screens, but it's not required for just the progress bar). The error message should be taken out in a future version. 5.25. When suspending it fails with "Failed to initialise the com- pression transform" The default hibernate configuration will try to use the lzf compressor. If the compressor is not available, you will get this error. You need to recompile your kernel with CONFIG_CRYPTO_LZF=y. Another cause is that hibernate 1.09 had an incompatibility with mawk, so that it would not set the compressor at all, giving this error. Solution is to use gawk or upgrade to hibernate 1.10. If you are using your own custom suspend script, you need to set the compressor/encryptor settings in /sys/power/suspend2 appropriately, or echo 0 > /sys/power/suspend2/compression/enabled and/or encryption/enabled if you don't want to use compression/encryption. The available compressor/encryptors are listed in /proc/crypto. 6. Modular TuxOnIce 6.1. I get messages about the size of struct module not agreeing when the initrd tries to insert my suspend modules. You built a new kernel and forgot the update the modules in the initrd. 6.2. The modules are installed fine but the swapwriter complains about not being able to access the suspend device. Did you insert IDE/SCSI/USB modules prior to the suspend modules? 6.3. How do I update my running kernel modules without rebooting into a new kernel? 1. Check release notes to ensure you don't need to install a new bzImage. 2. Apply new patches to the kernel tree. 3. make menuconfig modules modules_install 4. Update your initrd. Sample script for updating /boot/mm.img (a gziped initrd with bootsplash concatenated) while running the matching kernel version: #!/bin/bash # Assumes /mnt/initrd exists and that modules are located in /lib. MOUNT=/boot/mm.img echo Updating $MOUNT. mv -f $MOUNT $MOUNT.gz gunzip $MOUNT.gz mount $MOUNT /mnt/initrd -o loop rm -f /mnt/initrd/lib/* cp -f /lib/modules/`uname -r`/kernel/kernel/power/* /mnt/initrd/lib/ umount /mnt/initrd gzip $MOUNT splash -s -f /etc/bootsplash/themes/Mandrake-tux/config/bootsplash-1024x768.cfg >> $MOUNT.gz mv $MOUNT.gz $MOUNT 5. Unload old modules: for NAME in `lsmod | grep suspend | awk '{print $1}'`; do rmmod $NAME; done 6. Load new modules: modprobe toi_text; modprobe toi_swap; modprobe toi_lzf; modprobe toi_compression 6.4. How can I update my initrd (initramfs) on Fedora? Edit the /init file of your initramfs as so: o Login as root o mkdir myinitrd o cd myinitrd o gzip -dc < /boot/initrd-your-version-here.img | cpio -i o edit init by adding echo 1 > /sys/power/suspend2/do_resume near the top of the script (after mounting /proc but before mounting any drives) o find . | cpio -o -c |gzip -9 > /boot/initrd-your-version-here.img o hibernate :) 6.5. How can I update my initrd on Debian? See DebianInitrd on the wiki <###WIKI_URL###DistroAndHardwareSetup/DebianInitrd>. 7. Miscellaneous 7.1. What's left to do? TuxOnIce is reasonably mature software when it comes to the laptop or desktop. The main areas in which we'd still like to do some development are: - Hibernation to networked storage; - Hibernation support for clusters. 7.2. TuxOnIce seems nice, but can I use it for doing snapshots? You can use the "Keep Image" mode to perform a snapshot. With this enabled, the suspend image is not removed after resuming. This allows you to suspend once, but resume from the image multiple times. You must be very careful, as the image you save is linked to your filesystem state, including root, so all filesystems must be mounted read-only and left in an identical state to when the suspend image was created. 7.3. I can't capture the oops easily, what should I do? See Reporting Kernel Oopses on the wiki.