On Sunday, December 05, 2010, Dr. David Alan Gilbert wrote: > * Rafael J. Wysocki (rjw@xxxxxxx) wrote: > > On Saturday, December 04, 2010, Dr. David Alan Gilbert wrote: > > > * Rafael J. Wysocki (rjw@xxxxxxx) wrote: > > <snip> > > > > > > > > > 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. > > Except the blkid currently looks in the space where this new signature > lives to try and figure out what type of partition it is, and hence where to find > it's uuid. If you're saying that blkid should be looking somewhere else > (maybe the preceding 10 bytes?) to identify the partition fine, but at the moment > those 10 bytes are used by user space, whether they should be or not. > > > > > > > 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. > > The way I see it: > > 1) blkid should always be able to find the uuid of the > partition irrespective of whether swap then allows it to use it later. > > 2) But then as a separate statement I believe that we shouldn't require > a user to do a mkswap to recover from a failed hibernate. > > I can see (2) is a bit more contentious, but how does (1) get fixed? If the kernel finds a wrong image, it resets the signature and then reboots. I don't see any other way to solve it at the moment. 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
