Regression: resume from disk (hibernate) fails sometimes

[Kurt J. Bosch]

Binary package hint: initramfs-tools

On feisty resume from disk fails sometimes. Instead normal boot appears.

When looking into dmesg 'Attempt to manual resume' is missing (which is allways there normally).

It seems to me like
/usr/share/initramfs-tools/scripts/local-premount/resume (called from within initrd.img) is just exiting before calling /bin/resume for some reason sometimes.

I have resume=/dev/hda6 in kernel options and RESUME=/dev/hda6 in
/etc/initramfs-tools/conf.d/resume. This swap is on same physical disk as root is.

Before I upgraded from edgy there was no such problem.

I made a patch with wait for resume device similar to wait for root found in
/usr/share/initramfs-tools/scripts/local and panic when timeout occures or when
/sys/power/resume is missing to work around this or allow some further testing.

[Kurt J. Bosch (kujub-deactivatedaccount)]

OK ... did some reboots now for testing. Problem showed up one time and patched script reacted und wait seemed to fix things. That means /dev/hda6 realy didn't exist when first test occured (realy strange).

Unfortunately message was "resume: 66: log_begin_msg not found" so I have to submit a fixed patch (again) with /script/functions sourced.

[Kurt J. Bosch (kujub-deactivatedaccount)]

Please don't beat me - had to fix it again. :-/
$RESUME is not exported use $resume now for panic message.
(It should never come so far any way.)

[Adam Porter (alphapapa)]

I have a fresh install of Gutsy on my laptop and this happens to me as well. Hibernation succeeds, but on boot, sometimes it resumes properly, while other times it doesn't even try to load the hibernation image, and it fails to activate the swap partition because it's still a hibernation image. It boots up normally, runs fsck on the disks since they weren't cleanly unmounted, and I have to:

1. Manually run mkswap on the swap partition to make it a normal swap partition again
2. Change the UUID of the swap partition in /etc/fstab
3. Change the UUID of the swap partition in /etc/initramfs-tools/conf.d/resume
4. Run swapon -a to activate the swap partition
5. Run "sudo dpkg-reconfigure linux-image..." to recreate the initrd

Then I can hibernate again, but resuming may or may not work.

All of my partitions are in LVM. Root is /dev/mapper/vg-root, and swap is /dev/mapper/vg-swap; both are in the same volume group, named "vg".

[Adam Porter (alphapapa)]

After a bit more testing, it seems that the cycle is something like this;

1. Swap and everything is working.
2. I hibernate the system successfully.
3. I boot the system, and it resumes from hibernation successfully.
4. I hibernate the system successfully again.
5. I boot the system again, but it doesn't even try to load the swsusp image. It boots "normally," runs fsck to fix the not-cleanly-unmounted filesystems, and fails to activate the swap partition since it has a swsusp signature, not a normal swap signature.
6. I go through steps 1-5 in my last comment to reenable hibernation and swap.
7. I reboot just to make sure everything is hunky dory with the new kernel initrd.
8. Go back to step 1.

So basically, hibernation works, but resuming only works the first time. I have no idea why. I would be glad to help debug this.

Please mark this bug as confirmed and give it the appropriate priority. It would be a shame for Feisty to be released with this as well.

[Adam Porter (alphapapa)]

Oops, I meant Hardy, of course, not Feisty.

[Daniel Hahler (blueyed)]

I cannot confirm this behaviour, although I've only used pm-hibernate (from KDE4) and the gnome Hibernat function lately.
Kurt, do you still experience this with Hardy, too?

Adam, does the patch from Kurt work for you?

[Adam Porter (alphapapa)]

Ouch, I just had a nasty run-in with the aftereffects of this bug.
After a failed resume, there was no swap, but I didn't fix the swap
partition, I just left it alone. After another reboot, the kernel
*did* resume using the image in swap, but that was after using the
system for a while. This naturally resulted in extensive fs
corruption because of the unmounted fs data in the swsusp image, but
luckily, it mostly only affected some log files. (Another testament
to Linux and FOSS; something similar on Windows would have probably
resulted in reinstalling the OS). It took several manual fsck's but
it got fixed and is ok now.

I will try the patch now and let you know how it goes.

[Adam Porter (alphapapa)]

Well, so far it seems better; I've hibernated and resumed a couple of
times without any trouble. I'll let you know if I have any more
trouble, but maybe this has fixed it.

Just to make sure I did it right, here's what I did:

1. Patched the file.
2. Ran dpkg-reconfigure on the kernel package.
3. Hibernated...

[Leann Ogasawara (leannogasawara)]

Which specific version of the Ubuntu kernel you are running: cat /proc/version_signature

Care to test the latest 2.6.24-10 release and verify this issue still exists? If it does, please attach the following information as separate attachments:

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies .

Also please note that even though the symptoms of this bug that you are experiencing may be the same, it really is Hardware specific. You should open a new bug report if your hardware differs from the original bug reporter.

Thanks.

[Soren Hansen (soren)]

I believe this bug was fixed with my initramfs-tools 0.85eubuntu26 upload a few hours ago. It should trickle down to the mirrors within a few hours. Enjoy! :)

[Adam Porter (alphapapa)]

Can this be released for Gutsy as well?

On Fri, Feb 29, 2008 at 11:22 PM, Soren Hansen <email address hidden> wrote:
> I believe this bug was fixed with my initramfs-tools 0.85eubuntu26
> upload a few hours ago. It should trickle down to the mirrors within a
> few hours. Enjoy! :)
>
>
> ** Changed in: initramfs-tools (Ubuntu)
> Status: Confirmed => Fix Released
>
>
>
> --
> Regression: resume from disk (hibernate) fails sometimes
> https://bugs.launchpad.net/bugs/93039
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Adam Porter (alphapapa)]

Shouldn't this be marked as fixed?

On Tue, Mar 11, 2008 at 11:15 AM, Leann Ogasawara <email address hidden> wrote:
> ** Changed in: linux (Ubuntu)
> Status: Incomplete => Invalid
>
> --
>
>
> Regression: resume from disk (hibernate) fails sometimes
> https://bugs.launchpad.net/bugs/93039
> You received this bug notification because you are a direct subscriber
> of the bug.
>