kernel hibernate signature has changed from S1SUSPEND to LINHIB0001

Checked and this bug exists in Debians util-linux and upstream (http://ftp.kernel.org/pub/linux/utils/util-linux/v2.18/).

Note the LINHIB0001 in signature location:

0000fc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000fd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000fe0: 0100 0000 0000 0000 0100 0000 5357 4150 ............SWAP
0000ff0: 5350 4143 4532 4c49 4e48 4942 3030 3031 SPACE2LINHIB0001
0001000: 0200 0000 0000 0000 0300 0000 0000 0000 ................
0001010: 0400 0000 0000 0000 0500 0000 0000 0000 ................

This seems to be a result of the kernel commit below:

  commit 3624eb04c24861ab296842414f9752a393e68372
  Author: Rafael J. Wysocki <email address hidden>
  Date: Mon Oct 4 22:08:12 2010 +0200

    PM / Hibernate: Modify signature used to mark swap

    Since we are adding compression to the kernel's hibernate code,
    change signature used by it to mark swap spaces, so that earlier
    kernels don't attempt to restore compressed images they cannot
    handle.

    Signed-off-by: Rafael J. Wysocki <email address hidden>
    Acked-by: Pavel Machek <email address hidden>

For info, an "unused" (mkswap'ed only) swap image looks like this:

0000fc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000fd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000fe0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000ff0: 0000 0000 0000 5357 4150 5350 4143 4532 ......SWAPSPACE2
0001000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0001010: 0000 0000 0000 0000 0000 0000 0000 0000 ................

A used swap image (where the kernel has written to it) looks like this:

0000fc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000fd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000fe0: 0100 0000 0000 0000 0100 0000 5357 4150 ............SWAP
0000ff0: 5350 4143 4532 5357 4150 5350 4143 4532 SPACE2SWAPSPACE2
0001000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0001010: 0000 0000 0000 0000 0000 0000 0000 0000 ................

When we end up in this situation the kernel has already had its oppotunity to resume from the image, and as it has not fixed the swap signature has chosen not to do so. The current behaviour of swapon is to restore the swap signature if it finds any one of the hibernate IDs, cleaning up the image. It seems appropriate to add this new signature to both blkid and swapon such that the same processing is used.

Fix (for testing!) created in PPA:

  https://launchpad.net/~jamesodhunt/+archive/cerulean/+packages

Ah, good someone else spotted this - see discussion at
  http://www.spinics.net/lists/util-linux-ng/msg03650.html

where I prodded the upstream guys and my bug 682176 which should probably marked as a dupe of this.

Dave

James' PPA fixes work for me, resuming from hibernation works again. Thank you!

EVERYONE BE CAREFUL: The hibernation image isn't invalidated on resuming failure. I encountered this bug, installed the fixes from PPA, rebooted and it restored the image! => serious file system corruption.

busybox has the same problem.

Comments from Andy on irc:

The issue is if we have natty and hibernate, reboot, hibernate is not detected and swap is lost. we then fix the tools and reboot and it finds and resume from the image and the filesystem no longer matches the memory image and BLAMMO bad corruption of /. So if you install your fixes to the tools, we need to invalidate the swap marker as the contents are definatly BAD to use.
_____________

Note that we also need to update busybox and libmagic1 to understand the new LINHIB0001 signature.

Updated ppa to (hopefully - anyone is feeling brave...?) avoid data corruption issues:

  https://launchpad.net/~jamesodhunt/+archive/cerulean/

Stil require updates to busybox and libmagic1 (in progress...), although these updates are not required unless you want busybox or /usr/bin/file to recognize compressed hibernate images.

Although it builds locally, util-linux is failing to build in launchpad. There is a large queue of jobs in front of mine, so we have to wait to see what a rebuild shows...

Busybox code is fixed (but again, not yet built). file (libmagic) fix is available - awaiting feedback from upstream.

I'd suspect to rethink the fix. From mainline kernel git:

Author: Rafael J. Wysocki <email address hidden> 2010-12-11 21:46:44
Committer: Rafael J. Wysocki <email address hidden> 2010-12-16 17:08:58

    PM / Hibernate: Restore old swap signature to avoid user space breakage

    Commit 3624eb0 (PM / Hibernate: Modify signature used to mark swap)
    attempted to modify hibernate signature used to mark swap partitions
    containing hibernation images, so that old kernels don't try to
    handle compressed images. However, this change broke resume from
    hibernation on Fedora 14 that apparently doesn't pass the resume=
    argument to the kernel and tries to trigger resume from early user
    space. This doesn't work, because the signature is now different,
    so the old signature has to be restored to avoid the problem.

    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22732 .

    Reported-by: Dr. David Alan Gilbert <email address hidden>
    Reported-by: Zhang Rui <email address hidden>
    Reported-by: Pascal Chapperon <email address hidden>
    Signed-off-by: Rafael J. Wysocki <email address hidden>

(Ah, read "suspect" as "suggest" please.)

(BTW, the above is commit be8cd644c49dca4212e975455c8e7119b848ebe8. Argh.)

Yes it seems like they may have rethought the change to the signature. This would negate the need for any changes. Hmmm.

Have notified upstreams ("busybox" and "file") that they may wish to revert this change:

- busybox
  http://lists.busybox.net/pipermail/busybox/2011-January/074264.html

- file
  (no 2011 archive available yet)

For reference, original upstream patches are here:

- busybox
  http://lists.busybox.net/pipermail/busybox/2010-December/074126.html

- file
  http://mx.gw.com/pipermail/file/2010/000681.html

Due to the LINHIB0001 kernel change being reverted, there is no need for this change. As such, this bug will not be progressed, unless the kernel change is re-applied.