HOWTO: Use swapfile instead of partition and hibernate

[suar]

a swap_offset utility was mentioned

proper spelling is swap-offset

Then I made an 07_hibernation file in /etc/grub.d/ out of the 40_custom file already given there.
I picked 07, so I have this on top and selected in grub during boot time and I wouldn' t have to change the grub file in /etc/default/ also.

it's much better to adjust /etc/default/grub by changing GRUB_CMDLINE_LINUX_DEFAULT="splash resume=UUID==3f729a36-0b10-447c-83cf-d41deadbeef6 resume_offset=666" where UUID is appropriate id for partition where your swapfile is located and resume_offset is value returned by swap-offset. This way only "normal" and not "recovery" entries of grub menu will be affected. Also it's easier to edit by users and error-prone because that's less text to enter Don't forget to run sudo update-grub after this. Note: you have to reboot to use suspend-to-disk after this because that's the only wy to pass this options from grub to kernel.

[ronocdh]

I have trouble getting beyond this point:

sudo filefrag -v /swapfile | grep "First block:"

When I enter that command, I get no output whatsoever. If I trim it down to:

sudo filefrag -v /swapfile | grep "F"

then I get:

Filesystem type is: ef53
Filesystem cylinder groups is approximately 445
File size of 3100MB.swap is 3174400000 (775000 blocks, blocksize 4096)

Any ideas on why I'm not getting any output for "First block"? The file is already formatted as swapspace. I've tried running the filefrag command with the swapfile turned on and off.

[Operan]

proper spelling is swap-offset it's much better to adjust /etc/default/grub by changing GRUB_CMDLINE_LINUX_DEFAULT="splash resume=UUID==3f729a36-0b10-447c-83cf-d41deadbeef6 resume_offset=666" where UUID is appropriate id for partition where your swapfile is located and resume_offset is value returned by swap-offset. This way only "normal" and not "recovery" entries of grub menu will be affected. Also it's easier to edit by users and error-prone because that's less text to enter Don't forget to run sudo update-grub after this. Note: you have to reboot to use suspend-to-disk after this because that's the only wy to pass this options from grub to kernel.

Thanks you. I did like that, and my machine can hibernate. The issue that it seems not to be able to restore from resume state. I've waited about 4 minutes while the only cursor blinked on the gray (or black) screen. 4 or 5 mins is not acceptable.
Any suggestion? How long does hibernation take you to restore from resume state in swap file?

I have trouble getting beyond this point:

sudo filefrag -v /swapfile | grep "First block:"

When I enter that command, I get no output whatsoever. If I trim it down to:

sudo filefrag -v /swapfile | grep "F"

then I get:

Filesystem type is: ef53
Filesystem cylinder groups is approximately 445
File size of 3100MB.swap is 3174400000 (775000 blocks, blocksize 4096)

Any ideas on why I'm not getting any output for "First block"? The file is already formatted as swapspace. I've tried running the filefrag command with the swapfile turned on and off.

You should read the post by RBertrand carefully!

[suar]

Any suggestion? How long does hibernation take you to restore from resume state in swap file?

Have no idea what's wrong in your case. For me it was about 10-30 seconds of disk drive activity before I see gnome's lock screen with prompt to enter password. Are you sure that you carefully followed how-to steps? uswsusp is installed and so on?

[ronocdh]

You should read the post by RBertrand carefully!

Thanks! That's gotten me much further. Now when I try to do sudo s2disk, it goes to an all-text screen, says it successfully created the snapshot, then counts up to 100% on "Saving 352645 image data pages." Once it reaches 100%, however, it prints "Done" and I'm right back at my desktop!

So, clearly there's more work to be done, but I'll be darned if I know where to start! I'll post back if I find anything of substance, naturally.

[excogitation]

Just got it working with Karmic (Kubuntu amd64).

I'm still trying to make it work with Karmic (x86) but can't manage.

When adding resume=UUID= and resume_offset= to the boot options the system doesn't boot up with that particular entry.

menuentry "Ubuntu, Linux 2.6.31-17-generic (Hibernate)" {
        recordfail=1
        if [ -n  ]; then save_env recordfail; fi
	set quiet=1
	saved_entry=
	save_env saved_entry
	insmod ext2
	set root=(hd0,3)
	search --no-floppy --fs-uuid --set 1cc935ad-91a9-4be3-ae71-0a23b1ade94f
	linux	/boot/vmlinuz-2.6.31-17-generic root=UUID=1cc935ad-91a9-4be3-ae71-0a23b1ade94f ro resume=UUID=1cc935ad-91a9-4be3-ae71-0a23b1ade94f resume_offset=598016
	initrd	/boot/initrd.img-2.6.31-17-generic
}

How about fixing it for everyone: #313724

[AkifTariq]

I have the same problem as with ronocdh. I cannot get any output of the command:
sudo filefrag -v /swapfile | grep "First block:"

Can anyone please help me on this? I have tried everything to get the output (turning swap off and formatting swap etc.)

ronocdh and I have one thing in common. His swap file is just over 3 GB as mine. Can this be the cause of the problem? Shall I try smaller swap file?

I am stuck at this point. Please help.

[ronocdh]

I have the same problem as with ronocdh. I cannot get any output of the command:
sudo filefrag -v /swapfile | grep "First block:"

Can anyone please help me on this? I have tried everything to get the output (turning swap off and formatting swap etc.)

ronocdh and I have one thing in common. His swap file is just over 3 GB as mine. Can this be the cause of the problem? Shall I try smaller swap file?

I am stuck at this point. Please help.

Thanks for the followup, AkifTariq! Very interesting that you notice we both have large(r than normal?) swap files. I'll give it another go this weekend, as I recently freed up a ton of space on my laptop.

I'll definitely try with multiple swap files and see whether that affects anything. I'm doing this on a MacBook Pro (3 years old) with 3GB of RAM, so I don't think s2disk will work with a smaller swap file.

[RBertrand]

Just a follow-up with some experience with hibernation, maybe some other (K)Ubuntu users will be helped with this, I think ronocdh and AkifTariq could be experiencing similar problems...

As I am a linux newbie, I'm not sure whether I am 100% correct about my conclusions, so I am going to write out my experiences.

Bottom line:
- Hibernation using the kernel seems to be broken with ext4 fs; possibly because of journal checks during boot or a bug concerning large files on ext4 partitions (see https://bugs.launchpad.net/ubuntu/+s...ux/+bug/453579 )
- However, I managed to get it working with uswsusp (s2disk)
- filefrag has a bug when used on large files (> 4G) on ext3

What I did:
I made a mistake updating my Kubuntu Karmic amd64, leaving it non-usable, so I decided to reinstall. As I experienced numerous rough edges using Kubuntu, I decided to try the Gnome 64bit version and see whether this distro delivered a better and more integrated application suite. I don't know why, but somewhere in the process I went with the defaults Ubuntu presented and installed the system onto an ext4 partition.

I followed iva2k's guide, but was unable to get hibernation working. First, I thought this was because I forgot to set the resume-file in /etc/initramfs-tools/conf.d/, but after correcting that going into hibernation worked, but resume still didn't work, leaving the PC hanging without usable prompt after going through the local-premount scripts where resume is called and I had to reboot the PC from scratch.

Because this wasn't going to work, I installed uswsusp and checked out s2disk. First, that didn't work either. That seemed due to the fact that all parameters in grub told the kernel to use its own resume option. I deleted the offset value from grub and after a s2disk hibernation, the PC came back to life (and a lot faster than it did before with kernel based resume).

But at that point, I was unable to modify the Ubuntu (Gnome) startmenu and the power management to point to s2disk instead of the "normal" hibernation AND Gnome was a bit too polished to my liking, so I decided to go back to Kubuntu, where I also knew hibernation did work before.

Going back to Kubuntu Karmic amd64...
I formatted the root partition and installed Kubuntu. Then I followed iva2k's procedure again and hibernation DIDN' T WORK!? I had exactly the same issue that I had with Ubuntu Karmic amd64.

But then I remembered I had no problem with filefrag, however! The output still didn't contain the "First block:" string, as is expected, but it didn't go into an endless loop. At that point, I knew what the difference was: the first time I installed Kubuntu, I decided to stick with ext3, because there were numerous bugs, and one of them was that ext4 possibly corrupted large files (>512MB). And my swapfile is a large file (6GB)...

Looking into the logs, I can see that resume finds the correct hibernation image, but fails to resume correctly. Later on in the boot process, it tries to resume again "manually" (I don' t know what that is). Around that time, the journal is read also, so that could be interfering with the resume process, but it can also originate from large file corruption on ext4, reported by several users. I don't know.

So I installed Kubunutu again onto ext3 and I configured hibernation. Again, filefrag went bezerk, so I used swap-offset instead. But I did not need to use s2disk, because after booting with the said kernel parameters, the hibernation and resume worked again.

I hope for you this ext4-thingy is the cause of your hibernation troubles, because you might find a solution by ging to ext3 as I did.

Note: suspend (or more exactly: resume from suspend) worked on my box only after installing the 185 nVidia drivers, not with the default X-window drivers. As I checked suspend before setting up hibernation, it is possible that you need to install the correct video drivers before resume from hibernation will work.

The behaviour of the PC is different when hanging on video drivers during resume (my box beeped not being able to present a desktop-image and I had working terminals with an login prompt) and you might find out in the logs whether this plays a role in your situation.

[suar]

This how-to was wroking perfectly with ext4 & 10.04 Unfortunately it will not work with btrfs and 10.10 due to incompatibilities with swapon. As a possible workaround it is mentioned that we can use loopback device. Unfortunately I was unable to find any sort of instructions on how exactly to do that. If somebody managed to figure it out - please share.