xfs_repair: Sorry, could not find valid secondary superblock
 

A friend's mdv2009.1 box locked up during a big printing job and he had to force a shutdown with Alt-SysRq-R S E I U B. Upon reboot it came back in single user mode and would not mount the hard disk. I booted it from a live CD and performed the following on hda1, what I presume to be the root partition:

# mount /dev/hda1
mount: wrong fs type, bad option, bad superblock on /dev/hda1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

# dmesg | tail
XFS: bad version
XFS: SB validate failed
XFS: bad version
XFS: SB validate failed
XFS: bad version
XFS: SB validate failed
XFS: bad version
XFS: SB validate failed
XFS: bad version
XFS: SB validate failed

# badblocks -sn /dev/hda1
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done

xfs_check /dev/hda1
bad sb version # 0xb4b4 in ag 0
bad sb version # 0xb4a4 in ag 1
(really big snip)
sb_fdblocks 653, counted 1677
WARNING: this may be a newer XFS filesystem.

# xfs_repair /dev/hda1
bad primary superblock - bad version number !!!
attempting to find secondary superblock...
(big snip)
Sorry, could not find valid secondary superblock
Exiting now.

Searching the web I find numerous requests for help with the same issue but no one reports success. So I'm out of ideas. What else might I try to bring this box back to life?

I've had failed xfs filesystems, thanks to that crap called vmware->(beWare).

I used UFS Explorer to scan/recover my lost data. It's shareware and works like a charm. I've been using open source, freeware, whatever you choose to call it, for 20 years and can count on one hand the number of shareware programs that I've paid for and would recommend, and this is one of them.

I had a 10TB volume group with several logical volumes, each with an XFS filesystem. The complete 10TB volume group was copied to a 2nd VG but with only 1 LV, 1 XFS filesystem. Both disks were clobbered by vmware.

UFS Explorer recovered all of the data that was grouped into seperate LV, and 90% of the data with a single 10TB XFS filesystem. Unfortunately sometimes the filename is lost and you get a file by inode, but the exhaustive scan looks at the underlying data and recovers many known types of files.

If you have a second disk, it's always a good idea to clone the disk block by block (ddrescue) and attempt recovery on the clone first. UFS Explorer can't do an inplace data recovery anyway, you'll need a 2nd disk to copy the recovered data to.

Good luck