About three weeks ago my employer asked me to shrink the swap partition of a GNU/Linux Ubuntu 8.04 system so as to gain several gigabytes for the root filesystem. After resizing, hibernation failed in a way that although the hibernation process was without any error, turning on the machine again didn't resume the hibernated state. After resizing, the swap space still had enough space for hibernation for sure, and the UUID for the swap space in `/etc/fstab' had been adjusted as well. Just last Friday my employer tried again to solve this problem by googling for information. After a while I got a call, and this time my employer and I found the culprit. Having such an employer is so much fun!

First, my employer tried to install uswsusp following a thread in the Ubuntu forum. After the installation, he tried to run `s2disk' that failed with the following error message:

s2disk: Could not stat the resume device file. Reason: No such file or directory

`s2both' also didn't work with the following error message, which is just the same:

s2both: Could not stat the resume device file. Reason: No such file or directory

So, he called me and had me drill down the problem further. I read the man page of `s2disk' and checked `/etc/uswsusp.conf'. It turned out that the value for key `resume device' was in a wrong UUID. So, I fixed the UUID. But, still the error message about not being able to find the image disk persisted. So, I realized that uswsusp didn't recognize UUID and had to be supplied with `/dev/*'. So, I changed that to `/dev/*'. Now `s2disk' worked. But, when the machine was powered back on, the state was not resumed. So, the hibernation failed. So, my employer suggested to purge uswsusp and install it again. Doing it I saw in the uswsusp installation process the following message:

The swap file or partition that was found in uswsusp's configuration file is not active. In most cases this means userspace software suspend will not work for you and you will need to choose (or let uswsusp choose) another swap space. In some corner cases however, this can be what you want.

Continue without a valid swap space?

Answering `yes' caused the key `resume device' in `/etc/uswsusp.conf' to have a wrong UUID again instead of `/dev/*'. Since the UUID of the swap device listed in `/etc/fstab' was correct, I wondered from where uswsusp got the wrong UUID. After purging and reinstalling uswsusp several times, I realized that update-initramfs was invoked at the end of the installation process provided that I answered `yes' for the question `Continue without a valid swap space?'. So, I went to `/etc/initramfs-tools' and did `ls -r *'. There I saw `resume' under `conf.d'. Seeing its content, I realized that uswsusp had been taking the value for its `resume device' from this file. So, I fixed the content of `resume', purged and installed uswsusp again. This time it was without the error message. Now hibernation worked successfully.

Although I was happy enough with the result, my employer said, "I have a hunch that now the original hibernate should work since it stopped working after the resizing process changed the UUID of the swap space and `/etc/initramfs-tools/conf.d/resume' is not updated to the right UUID." He was right! Now the original hibernate works perfectly and so I purged uswsusp. Heh, I should have got such a hunch myself ;-)

So, I conclude the following points:

1. `/etc/initramfs-tools/conf.d/resume' belongs to the original hibernate function.
2. uswsusp reads `/etc/initramfs-tools/conf.d/resume' to initialize its `resume device' in `/etc/uswsusp.conf'.
3. uswsusp cannot understand UUID format (bug filed: https://bugs.launchpad.net/bugs/404085).
4. gparted changes the UUID of the swap partition although only moving or resizing operation is applied. It should not be like this since resizing a reiserfs filesystem, for example, does not change its UUID. (bug filed: https://bugs.launchpad.net/bugs/404095).