[lucid regression] does not resume from hibernation, restarts fresh

Bug #499940 reported by Per Ångström
218
This bug affects 42 people
Affects Status Importance Assigned to Milestone
hibernate (Ubuntu)
Invalid
Undecided
Unassigned
Lucid
Invalid
Undecided
Unassigned
initramfs-tools (Ubuntu)
Fix Released
Undecided
Steve Langasek
Lucid
Fix Released
Undecided
Steve Langasek
linux (Ubuntu)
Invalid
High
Andy Whitcroft
Lucid
Invalid
High
Andy Whitcroft

Bug Description

Binary package hint: pm-utils

My laptop no longer resumes after hibernation, it restarts fresh. This used to work fine in Jaunty, and in Lucid until some week ago, so there must be some recent regression. Suspend to RAM works fine.

I don't know whether it's related, but I often get this warning on running apt-get upgrade:
cryptsetup: WARNING: found more than one resume device candidate:
                     /dev/sda5
                     UUID=51aad372-2afa-4550-928d-6387e153d80e
In fact that is one and the same partition, see bug #497110 for more details on that.

ProblemType: Bug
Architecture: amd64
Date: Wed Dec 23 20:38:40 2009
DistroRelease: Ubuntu 10.04
Package: pm-utils 1.3.0~rc1-0ubuntu1
PackageArchitecture: all
ProcVersionSignature: Ubuntu 2.6.32-9.13-generic
SourcePackage: pm-utils
Tags: lucid
Uname: Linux 2.6.32-9-generic x86_64

Revision history for this message
Per Ångström (autark) wrote :
Revision history for this message
Per Ångström (autark) wrote :
Revision history for this message
Per Ångström (autark) wrote :

In the log posted above, there is a successful hibernation and resume at the very top. At the bottom, there is a hibernation without a resume.

Revision history for this message
Per Ångström (autark) wrote :

After an unsuccessful resume, during the boot, I can see the following message on the console:
swapon: /dev/sda5: software suspend data detected. Rewriting the swap signature.

After that, fdisk has to recover the journal on my root partition.

Revision history for this message
Per Ångström (autark) wrote :

I'm seeing the same problem on my second laptop, also running Lucid. Hibernation works flawlessly under Jaunty. Confirming bug.

Changed in pm-utils (Ubuntu):
status: New → Confirmed
Revision history for this message
Chow Loong Jin (hyperair) wrote :

Shifting to linux. If it has actually powered down after hibernation has been triggered, then pm-utils has done its job. It might be initramfs-tools' fault though. Perhaps the resume partition is not set properly?

Please also upload your /etc/fstab (at least the swap entry) and the /etc/initramfs-tools/conf.d/resume file.

affects: pm-utils (Ubuntu) → linux (Ubuntu)
Revision history for this message
Per Ångström (autark) wrote :

From my second laptop:
Relevant part of /etc/fstab:
# swap was on /dev/sda10 during installation
UUID=2a4d2eac-9fba-4760-849b-e366ea52a359 none swap sw 0 0

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=2a4d2eac-9fba-4760-849b-e366ea52a359

I have not noticed the cryptsetup warning on this machine, so maybe that's not relevant.

Revision history for this message
Per Ångström (autark) wrote :

From the first machine (the one of the original bug description):
From /etc/fstab:
# /dev/sda5
UUID=51aad372-2afa-4550-928d-6387e153d80e none swap sw 0 0

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=51aad372-2afa-4550-928d-6387e153d80e

Revision history for this message
Per Ångström (autark) wrote :

I tried changing /etc/initramfs-tools/conf.d/resume
to "RESUME=/dev/sda5", but that didn't change anything.

Revision history for this message
Per Ångström (autark) wrote :

I find that resume works on the first machine if I add "resume=/dev/sda5" to the kernel command line. Will try the same thing on the second machine later.

Martin Pitt (pitti)
tags: added: regression-potential
removed: regression
Changed in linux (Ubuntu Lucid):
importance: Undecided → High
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
Changed in linux (Ubuntu Lucid):
status: Confirmed → New
Revision history for this message
Per Ångström (autark) wrote :

I can confirm that appending "resume=/dev/sda10" to the kernel command line of the second machine also works.

Steve Langasek (vorlon)
Changed in linux (Ubuntu Lucid):
milestone: none → ubuntu-10.04-beta-1
Martin Pitt (pitti)
Changed in linux (Ubuntu Lucid):
status: New → Confirmed
Revision history for this message
Yves Lavoie (yves-lavoie-ing) wrote :

resume=/dev/hda7 doesn't help here and I am running without initramfs.
Swap signature is always rewritten on boot and then fsck removes orphans on my disks.
Annoying.

Revision history for this message
ibidem (ibid-ag) wrote :

I'm seeing the same problem here...I will need to figure out which swap partition it's using before trying the resume=/dev/sda* option. Yves, you might check if hda7 is the right partition.

Revision history for this message
Per Ångström (autark) wrote :

@Yves Lavoie: If you are having fsck issues after hibernation, that could be a sign of your machine having trouble hibernating properly. A proper hibernation implementation should sync the file system before powering down.

Revision history for this message
ibidem (ibid-ag) wrote :

The resume=/dev/sda* method works for me; I added it to /etc/default/grub and ran update-grub to make it permanent.
Essentially it would just be a small tweak in the setup scripts to fix, specifying one more kernel option.

I do see fsck running ("recovering journal") when I resume, even though resume is working properly.
It's in the boot messages on tty1.

Revision history for this message
Charles Curley (charlescurley) wrote :

I tried ibidem's process at comment #15 on my Lenovo R51. It did not work for me. I did:

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda6"
GRUB_CMDLINE_LINUX="resume=/dev/sda6"

[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.31-17-generic root=UUID=cd2f2481-4853-443c-8ff7-6609c6b45db5 ro resume=/dev/sda6 resume=/dev/sda6

(Later experimentation indicated that you only need the _DEFAULT variable set.)

Revision history for this message
Charles Curley (charlescurley) wrote :

Right after adding comment 16 above, I tried to hibernate to test again. Now it goes through the mtions of shutting down, then immediately resumes. This is worse than useless.

Changed in linux (Ubuntu Lucid):
assignee: Canonical Kernel Team (canonical-kernel-team) → nobody
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

removed assignment of Canonical Kernel Team. Added a task for cryptsetup as we see: cryptsetup: WARNING: found more than one resume device candidate:
                     /dev/sda5
                     UUID=51aad372-2afa-4550-928d-6387e153d80e"

-JFo

Revision history for this message
Daniele Cruciani (daniele-smartango) wrote :

I tried Ibidem's way at comment #15 it does never resume, I attach message (of hibernate).
Restarting give blank screen, it seems it start (because wlan led blink), but I have no log of that and screen is blank

Steve Langasek (vorlon)
Changed in cryptsetup (Ubuntu Lucid):
assignee: nobody → Steve Langasek (vorlon)
Andy Whitcroft (apw)
Changed in linux (Ubuntu Lucid):
assignee: nobody → Andy Whitcroft (apw)
Revision history for this message
Steve Langasek (vorlon) wrote :

The cryptsetup message at initramfs generation time is a red herring. If the swap device is /dev/sda5, then cryptsetup isn't actually involved in resuming; this must be an initramfs-tools bug instead.

affects: cryptsetup (Ubuntu Lucid) → initramfs-tools (Ubuntu Lucid)
Revision history for this message
Peter Clifton (pcjc2) wrote :

I'm trying this:

--- /usr/share/initramfs-tools/init 2010-02-17 12:35:26.000000000 +0000
+++ init 2010-02-21 15:53:56.085750219 +0000
@@ -193,7 +193,7 @@
 done

 if [ -z "${noresume}" ]; then
- export resume=${RESUME}
+ export resume="/dev/disk/by-uuid/${RESUME#UUID=}"
 else
  export noresume
 fi

/etc/initramfs-tools/conf.d/resume contains a UUID=.... type resume string, but the /bin/resume binary in the initramfs rejects this type of partition identification.

Revision history for this message
Peter Clifton (pcjc2) wrote :

Apparently not enough, wait-for-root returns the swap type as swsuspend, and the resume script doesn't know that. I've fixed that too:

--- initramfs-tools-0.92bubuntu65/scripts/local-premount/resume 2010-02-17 12:35:26.000000000 +0000
+++ initramfs-tools-0.92bubuntu65+pcjc2.1/scripts/local-premount/resume 2010-02-21 16:29:24.000000000 +0000
@@ -24,7 +24,7 @@
 SWAPTYPE=$(wait-for-root "${resume}" ${RESUMEDELAY:-5})

 case "${SWAPTYPE}" in
- s1suspend|s2suspend|ulsuspend|tuxonice)
+ swsuspend|s1suspend|s2suspend|ulsuspend|tuxonice)
        # hardcode path, uswsusp ships an resume binary too
        if [ -n "${resume_offset}" ]; then
                /bin/resume ${resume} ${resume_offset} >/dev/null 2>&1

Now my machine resumes ok.

Revision history for this message
Peter Clifton (pcjc2) wrote :

Changes which fixed resume for me...

Revision history for this message
Steve Langasek (vorlon) wrote :

I can confirm that wait-for-root doesn't appear to be handling the UUID=... argument correctly, but this patch is also incorrect because it drops support for specifying the resume device as anything *other* than a UUID. This needs to be fixed in wait-for-root instead.

tags: added: patch
Revision history for this message
Peter Clifton (pcjc2) wrote :

Good point.. I just copied the UUID substitution from another place in the init scripts without noticing that it was one of many different handlings of the ROOT= variable.

Is the addition of swsuspend SWAPTYPE ok?

Steve Langasek (vorlon)
tags: removed: patch
Revision history for this message
Peter Clifton (pcjc2) wrote :

wait-for-root looks like it handles UUID=... file system types, but the /bin/resume binary in the initramfs does not..

Is this a bug in klibc, or do the initramfs scripts need to convert to the /dev/.... form as required by resume?

 fprintf(stderr, "Usage: %s /dev/<resumedevice> [offset]\n", progname);

Revision history for this message
Steve Langasek (vorlon) wrote :

Yes, the addition of swsuspend is fine, though I'm puzzled that this is needed now when it was never needed before.

Took another look at this in my initramfs, and it seems wait-for-root *does* handle UUID= values (dunno what went wrong the last time I checked), but /bin/resume does not. So a partial revert of the changes in 0.92bubuntu59 to scripts/local-premount/resume will probably fix this.

Revision history for this message
Peter Clifton (pcjc2) wrote :

How about this patch?

It factors out the UUID= and LABEL= handling into a function, and uses that for both root= and resume= handling.

I've not tested it with anything other than a UUID resume though.

Steve Langasek (vorlon)
Changed in linux (Ubuntu Lucid):
status: Confirmed → Invalid
Changed in initramfs-tools (Ubuntu Lucid):
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.92bubuntu66

---------------
initramfs-tools (0.92bubuntu66) lucid; urgency=low

  * scripts/local-premount/resume: wait-for-root will handle both UUID= and
    /dev/disk/by-uuid, but /bin/resume from klibc will only handle the latter,
    so revert the changes from 0.92bubuntu59 that dropped our fix-up of
    device name. LP: #499940.
  * scripts/local-premount/resume: also recognize 'swsuspend' as a valid fs
    type for a hibernation partition, since this is what udev returns for the
    in-kernel hibernate/resume handling. Thanks to Peter Clifton for noticing
    this!
  * scripts/local-premount/resume: call 'plymouth message' before resuming,
    to notify the user of the reason for the delay if the plymouth theme
    supports it.
 -- Steve Langasek <email address hidden> Mon, 22 Feb 2010 00:20:22 -0800

Changed in initramfs-tools (Ubuntu Lucid):
status: Fix Committed → Fix Released
Revision history for this message
Daniele Cruciani (daniele-smartango) wrote :

I still can't resume, system freeze

Revision history for this message
Per Ångström (autark) wrote : Re: [Bug 499940]

Daniele Smartango wrote:
> I still can't resume, system freeze

Resume from hibernation works on both of my machines now, after the fix.

This bug was about the computer not attempting to resume at all and
doing a normal boot. If you are still being unsuccesful, it's some other
bug.

Revision history for this message
Santiago Roland (santiago-roland) wrote :

I have an HP6735s and my notebook won't hibernate. It does suspend... but when trying to hibernate it do not turn off and hangs up. I have to press power button for some secs to restart again...

regards.

Revision history for this message
Mbarak A. Bujra (mbarak) wrote :

Resume didn't work for me until i changed this section of /usr/share/initramfs-tools/scripts/local-premount/resume :

From:
        # hardcode path, uswsusp ships an resume binary too
        if [ -n "${resume_offset}" ]; then
               /bin/resume ${resume} ${resume_offset} >/dev/null$
        else
                /bin/resume ${resume} >/dev/null 2>&1
        fi
        ;;

to

 /usr/lib/klibc/bin/resume etc...

I upgraded to Lucid beta1 from karmic

Also when resuming the screen got seriously corrupt (probably something to do with proprietary nvidia drivers, quiet scary actually) but, that's another bug.

Revision history for this message
Hélio Nunes (dedalu-dedalu) wrote :

Same here, after upgrade from karmic to Lucid (final).

initramfs-tools is up to date, UUID from /etc/fstab == /etc/initramfs-tools/conf.d/resume, but still not resuming... always normal boot.

I will try Mbarak solution since I do not have the /bin/resume file. (Isn't ln -s better?)

How can I collect more info? Since it is not fixed for updates from karmic...

Revision history for this message
JJA (jarmo-ahonen) wrote :

I just upgraded from Karmic to Lucid (final) and hibernate stopped working. I tried some of the workarounds, but with no success. What logs etc should I send here?

Revision history for this message
beefstu (stucurtis15) wrote :

I think I suffer from the same bug, I've found that a package called hibernate in synaptic (or "sudo apt-get hibernate") works for me. Then in the terminal just do "sudo hibernate" (I have to do "sudo hibernate --force" as my nvidia modules do not unload but all seems fine on resume)

Revision history for this message
Benjamin Halbrock (kontakt-bennis-blog) wrote :

Same Problem as JJA for me.

my /etc/initramfs-tools/conf.d/resume seems empty

if I run sudo /usr/sbin/pm-hibernate it hybernates - but doesn't resume.

PS: I have an encrypted home from the 9.04 installer.

I just upgraded from Karmic to Lucid (final) and hibernate stopped working. I tried some of the workarounds, but with no success. What logs etc should I send here?

Revision history for this message
Philippe Joyez (ubuntu-5-pjoyez) wrote :

Me too... but it's a recent regression

I normally always hibernate my system. This was working well before and after I upgraded from Karmic to lucid RC (except for a cursor glitch https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/564423 which is presumably unrelated). Then suddenly, one week ago my system suddenly stopped resuming from hibernate, always starting fresh (and with network allways disabled after an attempt to hibernate). From the Synaptic history, I suspect it could be related to the initramfs-tools updated from 0.92bubuntu77 to 0.92bubuntu78, or an accompanying change around that time.

Like above, I'm willing to help debugging the resume process. What info should I collect?

Changed in initramfs-tools (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Philippe et Al,
     Please open new bugs against the linux package for your issues. Due to differing fixes to address the problem for some hardware, I prefer to have a new bug to look at for each. I have marked this bug back to Fix Released.

Thanks!

~JFo

Changed in initramfs-tools (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Philippe Joyez (ubuntu-5-pjoyez) wrote :

OK. I understand.

So, as requested, we now have another bug with the exact same symptoms :https://bugs.launchpad.net/ubuntu/+bug/577916
Since the reports of Hélio Nunes, JJA, beefstu and Benjamin Halbrock came after the "fix released" I guess they should be considered as part of the new bug.

tags: added: patch
Revision history for this message
Rob (rhbowman-deactivatedaccount) wrote :

This issue is also present on several HP desktops at the company. The only solution at this time was to disable hibernation. The machines cannot resume on suspend either.

Raymond P (raymondfp)
Changed in initramfs-tools (Ubuntu):
status: Fix Released → Fix Committed
status: Fix Committed → Fix Released
tags: added: regression-release
removed: regression-potential
Changed in hibernate (Ubuntu):
status: New → Invalid
Changed in hibernate (Ubuntu Lucid):
status: New → Invalid
Revision history for this message
Tomislav (hefest) wrote :

I seem to be seeing the same behaviour on Oneiric Ocelot: hibernate appears to work, but the laptop later boots like it was shut down, rather than sent to hibernation. I have tried it several times and it is 100% reproducible. Should I file a separate bug report?

Revision history for this message
Steve Langasek (vorlon) wrote :

Yes, please file a new bug report.

Revision history for this message
Ivan Zorin (iaz) wrote :

Similar issue - bug #957999

Revision history for this message
Justin Cook (jcook713) wrote :

What worked for me was adding "resume=/dev/sda2" to the kernel command line on resume, as well as getting my UUIDs to match.
 This is the first time I've had hibernate successfully working, suspend always worked well.

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.