I see in other posts that "parted" is sometimes a culprit in these
problems. Indeed, in my case I did use "parted" to create a gpt
partition table on these xfs volumes and I was asked my parted to use
the secondary signature.
--- snip ---
i also remember something about parted (maybe...) finding a backup gpt
signature at the end of a disk, and "helpfully" copying it over the
front end if so. This was a bug. sgi guys do you remember?
But for this one has to invoke parted, and commit the operations done,
am I right?
if I recall, even invoking parted could do this.
--- snip ---
So maybe I got bit the same way. parted may be overwritten something
at the head of the volume. Is there any way to repair the super block
though? It seems that everyone agrees xfs can't do anything until it
has a super block somewhere and I don't seem to have one. If there's no
way to repair, then what about recovery? I see mention of possibly
doing an xfs dump to another disk, reformat the original volume, and
then xfs restore back. Is there any online procedure for how to do that
if it applies to me here?
Thomas Walker
David Chinner wrote:
On Thu, Mar 15, 2007 at 10:06:42AM -0400, Thomas Walker wrote:
The terminal shows a lot of "." dots running across the screen
quickly, and every few hours it says this;
.....................................................found candidate
secondary superblock...
unable to verify superblock, continuing...
found candidate secondary superblock...
unable to verify superblock, continuing...
The primary superblock is not good, and it's trying to find a valid
secondary superblock. Doesn't sound promising so far - reapir can't
start until a valid superblok is found....
|