Gergely Soos wrote:
> In my original email there was an attachment that contained the original
> boot sector, but anyway, here comes the hexdump Eric asked for:
Sorry, didn't open the tarfile :)
> 00000000 91 f0 1c 43 90 01 ba bf f7 ee 29 9a 1e 6c d5 aa
> 00000010 11 5a 12 cb 3b 29 cb ff 39 ce 4e d3 95 ec b9 39
> This looks like nothing to me...
I agree... something splattered on the disk it seems. How far does this
junk go on, I wonder?
> xfs_repair rejects all superblock candidates and exits saying something
> like: Sorry, cannot find valid secondary superblock.
> I'm not sure what a GPT is, but this is an IDE harddisk, I'm using kernel
> 2.6.20 and my xfs partition is /dev/hdd1
GPT is a disk partitioning scheme, and it puts backups at the end of the
disk (IIRC), which sometimes automatically gets restored to the front.
But this does not look like your case.
> Is there any way xfs_repair would accept the superblock as is and move on
> with the repairs?
Well, you want to be sure it matches. But - go looking through your
disk for "XFSB" and keep track of where the offsets are; you should find
your backup superblocks that way, and we can use xfs_db to get the
values out and perhaps restore your primary.
(you can probably do this on your own, but something like:
# dd if=/dev/hdd1 bs=4k | hexdump -C | grep XFSB
might do nicely)
xfs_repair should be better at using these by itself. If you can put
your metadump somewhere that I can get to it, maybe I can look and see
why repair is not succeeding...