Re: LINHIB0001 hibernate signature

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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?


Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/
--
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


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux