7. Other configurations

7.1 TuxOnIce compiled as modules (after 2.2.9)

Support for compiling TuxOnIce as modules was removed for quite a while, but has returned after the 2.2.9 release. Building TuxOnIce as modules lets you free the memory for other uses when not hibernating, which is particularly useful in embedded applications.

7.2 Using a swapfile

1. Create and activate your swap file:
   • # dd if=/dev/zero of=/path/to/swapfile bs=1M count=<size in MB>
   • # mkswap /path/to/swapfile
   • # swapon /path/to/swapfile
   • Make sure you know what device your swapfile is on (eg, /dev/hda4). If you're not sure, run mount and find the longest mountpoint that is a prefix to the path of the swapfile (eg, it might be /usr/local, /usr or just /). Read the corresponding device to this mountpoint.
2. Find out your header locations:

   • # cat /sys/power/tuxonice/headerlocations
     For swapfile `/path/to/swapfile               `, use resume=swap:/dev/<partition name>:0x2da2b4.
     

   • For example, if I know the swapfile is on /dev/hda1, then my "resume=" line becomes resume=swap:/dev/hda1:0x2da2b4
3. Enter your resume= line:
   • On the kernel command line either in lilo.conf, or GRUB's menu.lst, put the full resume=... parameter.
   • If you use the hibernate script, in hibernate.conf put SuspendDevice swap:/dev/hda1:0x2da2b4
   • If you use a custom hibernate script, enter echo swap:/dev/hda1:0x2da2b4 > /sys/power/tuxonice/resume somewhere before hibernating.
   Doing one of the last two changes above is not required, but if you don't you will have to reboot your machine before being able to hibernate to the swapfile.
4. Get your swap partition automatically enabled and disabled for hibernating:
   • By entering the name of your swapfile into /sys/power/tuxonice/swapfile before hibernating, TuxOnIce will automatically enable and disable the swapfile for you. This is not required, but merely a convenience.

Superfluous details

Specifying the resume= device simply tells TuxOnIce where to write and find the header that indicates the machine is suspended and where to find the rest of the image. The image itself is written to any available swapspace whether it be swapfile or swap partition. The actual order of swap devices that data is written to turns out to essentially be the order in which swap partitions are enabled. Hence it's entirely plausible if you have a normal swap partition (or file), and one turned on only for hibernating, that the entire image is contained in the first swap partition, but the header alone is in the second.

7.3 Swap on LVM/dm-crypt

This requires Suspend2 2.1.4.2 or later. You need to setup LVM/encrypted swap before TuxOnIce attempts to resume. This means you need an initrd or initramfs.

The linuxrc/init script on such an initrd/initramfs roughly needs to do the following steps:

1. Mount /sys and /proc.
2. Load the modules you need.
3. Make the device nodes you need, be it by starting udev or just mknod'ing them.
4. Start lvm. For example by issuing

   vgscan
   vgchange -a y
   

   or by using dmsetup.
5. ... or setup your encrypted swap.
6. echo 1 > /sys/power/tuxonice/do_resume
7. Only now is it safe to mount your roofs (if required).
8. Do other things init/linuxrc would normally do (mount --move /proc, /sys, /dev; pivot_root; etc)

Of course you need to make sure that all the binaries and libraries you need are on the initrd/initramfs.

7.4 Using an initrd/initramfs but TuxOnIce compiled in

If you are using an initrd, you MUST edit the linuxrc script to attempt to resume before filesystems are mounted. Do this by inserting the line:

echo 1 > /sys/power/tuxonice/do_resume

If you are using an initramfs, you will need to do the same thing to your /sbin/init script, else you will never be able to resume.

See the Modules FAQ for some distribution-specific tips.

7.5 Keep image mode

The idea behind keep-image mode is that when you have resumed, the image is not invalidated, meaning you can resume from it several times. This is useful in kiosk-type situations, or perhaps in computing labs, where you want to boot quickly to a known state, every time.

The only caveats with keep-image mode is that no filesystem that is backed on disk can be mounted read-write in the suspended image. Nor can they be modified without creating a new resume image. The two issues to keep in mind are that:

1. the kernel's filesystem drivers keep a partial copy of the state of the filesystem in memory, which is saved in the image. Thus, if the filesystem on disk is modified without the kernel in the saved image knowing, you will almost certainly cause severe filesystem corruption when it resumes.
2. the kernel also keeps a cache of files on the filesystem. If, for example, a file is read off disk from a read-only filesystem, and the file is subsequently modified without a new image being created, the kernel in the image will not be aware of this and you'll more than likely hit it's cached copy.

Memory-backed filesystems (eg, tmpfs) are safe - their state is restored to how things were at hibernation time. You may also mount filesystems after resuming without much concern.

To setup a system for keep-image mode, you setup your machine how you want it at resume time, then mount all your disk-backed filesystems read-only or unmounted.

Then (with a kernel compiled with keep-image mode - CONFIG_SUSPEND2_KEEP_IMAGE),

  echo 1 > /sys/power/tuxonice/keep_image

When you resume, the image is not invalidated, so you can resume from it as many times as you like. So long as the state of the filesystem on the hard disk does not change, you should be safe.