On Saturday, December 04, 2010, Dr. David Alan Gilbert wrote: > * Rafael J. Wysocki (rjw@xxxxxxx) wrote: > > On Monday, November 29, 2010, Karel Zak wrote: > > > On Sun, Nov 28, 2010 at 02:08:38AM +0000, Dr. David Alan Gilbert wrote: > > > > libblkid and friends stopped detecting my swap partition on > > > > my Ubuntu laptop that I'm running the bleeding edge natty repo on > > > > (e.g. wipefs shows nothing, and I can't get a uuid from blkid). > > > > It's running 2.6.37-2 kernel and this bug persists in the latest > > > > git from git.kernel.org/pub/scm/utils/util-linux-ng version 07b33...40a8 > > > > > > > > I think this is due to the change in the hibernate signature from > > > > this patch: > > > > > > > > http://www.gossamer-threads.com/lists/linux/kernel/1283551 > > > > > > It seems we still don't live in ideal world where userspace is > > > informed (e.g. by CC:) about all such important kernel changes ;-) > > > > Well, I had no idea it would cause any problems to happen for any user space. > > That is an internal kernel thing. > > Well it's a signature on a device, so hardly internal. Only the kernel uses it, though. > > > > If I look at the header of my partition I see: > > > > > > > > 0007740 027 ! \0 \0 \0 \0 \0 \0 001 \0 \0 \0 S W A P > > > > 17 21 00 00 00 00 00 00 01 00 00 00 53 57 41 50 > > > > 0007760 S P A C E 2 L I N H I B 0 0 0 1 > > > > 53 50 41 43 45 32 4c 49 4e 48 49 42 30 30 30 31 > > > > > > > > Looking at shlibs/blkid/src/superblocks/swap.c I see it's > > > > looking for the SWAPSPACE2 signature at the address where > > > > I ahve LINHIB0001. > > > > > > > > What's the right fix here? Is it to add the LINHIB0001 to the > > > > swsuspend match table? Or is it more subtle - the SWAPSPACE2 in my > > > > header above is 10 bytes earlier than the one that util-linux is looking > > > > for. How are these headers supposed to work - should that LINHIB0001 > > > > still be there or is it due to a failed resume? > > > > That is due to a failed resume. Running mkswap on the partition generally > > helps in those cases (which has nothing to do with the change above, because > > you will still have S1SUSPEND instead of SWAPSPACE2 in there). > > Hmm, but what's the expected behaviour after a failed resume from hibernate? > Surely someone shouldn't have to run mkswap to fix up their system after a trivial > failure like that? That's a problem with the kernel's built-in hibernation. The original signature should be restored automatically by the kernel in such cases, but there were problems with users who started a wrong kernel to resume and then wanted to repreat that without losing the image. I'm not sure if that's a valid reason to avoid restoring the signature, though. Anyway, s2disk handles that correctly I believe. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
