Hibernate won't resume after image was successfully loaded

Bug #1159205 reported by Rainer Rohde on 2013-03-23
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
hibernate (Ubuntu)
Undecided
Unassigned

Bug Description

It seems as if hibernate writes the image successfully, but doesn't continue after restarting when finished loading the image and hangs indefinitely.

See screen-photo attached.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: hibernate 2.0+15+g88d54a8-1
ProcVersionSignature: Ubuntu 3.8.0-8.17-generic 3.8.0
Uname: Linux 3.8.0-8-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.9.2-0ubuntu2
Architecture: amd64
Date: Sat Mar 23 13:35:34 2013
EcryptfsInUse: Yes
MarkForUpload: True
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: hibernate
UpgradeStatus: No upgrade log present (probably fresh install)

Rainer Rohde (rainer-rohde) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in hibernate (Ubuntu):
status: New → Confirmed
Eric Ding (ericding-alum) wrote :

This is happening for me on my Thinkpad R61 after upgrading to Ubuntu 13.04 (kernel 3.8.0-19), but it was working fine with the leftover kernel from Ubuntu 12.10 (kernel 3.5.0-27).

Eric Ding (ericding-alum) wrote :

I just tested with a variety of mainline kernels from kernel-ppa, and am confused by what I found. I observed similar freezes while trying to resume from hibernate using all of the following versions: 3.5.0, 3.5.7, 3.6.11, 3.7.10, 3.9.0. I don't understand why resume from hibernate works fine with the 3.5.0-27 Ubuntu kernel and not the mainline 3.5.0 kernel, but that's what I've observed, for whatever it may be worth.

Eric Ding (ericding-alum) wrote :

I don't think this is a kernel bug per se -- I just tried reinstalling the 3.5.0-27 kernel that was working from debs, and now resume from hibernate is broken with that kernel as well. As a result, I've restored my backups from quantal, since this functionality is important to me. Could the might be with initramfs-tools or something else that changed between quantal and raring?

Eric Ding (ericding-alum) wrote :

Aha! I figured it out -- I'd worked around this in the previous release but forgotten about it. It's a bad interaction between uswsusp and plymouth. So this is basically a duplicate of #816859, which has an easy workaround, which makes me wonder why Ubuntu maintainers can't take the trouble of adding a two-line fix to /usr/share/initramfs-tools/scripts/local-premount/uswsusp.

In an attempt to upgrade-proof the workaround described in https://bugs.launchpad.net/ubuntu/+source/uswsusp/+bug/816859/comments/9, I've copied the script to /etc/initramfs-tools/scripts/local-premount/.

Rainer Rohde (rainer-rohde) wrote :

@Eric: Thank you so much -- this patch works.

And yes, I totally agree with your notion. The Ubuntu maintainers should be able to fix that for us. :)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers