[Top] [All Lists]

Can't mount or repair new xfs-partition after recompiling kernel

To: linux-xfs@xxxxxxxxxxx
Subject: Can't mount or repair new xfs-partition after recompiling kernel
From: piechoc@xxxxxxxxxxx (Thomas Piechocki)
Date: Sat, 26 Apr 2003 06:39:06 +0200
Reply-to: piechoc@xxxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: KMail/1.6.1-cool
Hello list-members,
unsatisfied with the ext3 and jfs filesystems I decided to switch to xfs. I am 
running Debian Sid with kernel 2.4.20, so I applied the xfs-patch deb-package 
for this kernel, which seems to be a snapshot from 2002-12-29. All went fine 
and finally all harddisks and partitions with exception of /boot had been 
formatted with xfs. 

Unfortunately I applied the patch after configuring the kernel via 'make-kpkg 
-added-patches xfs', which seems to cause no problems with the system or xfs 
at all, but makes it impossible to compile other modules for this kernel 
later. So I had to patch a clean kernel-source before configuring and 
compiling the kernel again, now with new nvidia modules. There were no 
changes with kernel version or configuring. 

After rebooting the new kernel I ran into a severe problem with one 
xfs-formatted partition (/dev/hdh2). When the new kernel booted it couldn't 
mount /dev/hdh2 and showed these errors: 

XFS: bad magic number
XFS: SB validate failed

'xfs_check /dev/hdh2' shows:

xfs_check: unexpected XFS SB magic number 0x00000000
xfs_check: read failed: Invalid argument
xfs_check: data size check failed
xfs_check: cannot read root inode (22)
xfs_check: cannot read realtime bitmap inode (22)
bad superblock magic number 0, giving up

'xfs_repair -n /dev/hdh2' of xfsprogs 2.4.4-1 does shows:

Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
found candidate secondary superblock...
unable to verify superblock, continuing...

and so on...
until it has finished its task:

.......Sorry, could not find valid secondary superblock
Exciting now.

This happens after a clean shutdown and reboot without any crashes. All other 
xfs-partitions mount fine and show no errors, even the third (/dev/hda3) at 
hdh (the first is swap). This harddisk is connected together with three other 
disks to a Promise onboard raid controller (PDC20276), but all work as normal 
ide-drives. I am sure that this is an xfs filesystem at /dev/hdh2 and I could 
read and write to its files without problems before recompiling and rebooting 
the new kernel. Lilo stays in the MBR of the first HD (hda), so it can't not 
be responsible for the destruction of the XFS superblock. 

Changing back to the old kernel/modules didn't help, neither booting  with 
other linux distributions (Knoppix 3.2, Mandrake 8.2). There are always the 
same error messages. 

I did a backup of the partition with dd (77.??? records in and out) and tried 
xfs_repair with log flushing and without -n, but with the same result. 

Now I have an untouched xfs-partition with a corrupted superblock and a backup 
image, perhaps both with all stored data, but no way to access it. Is there 
anybody here who can help me or give me some advices what to do next. Perhaps 
there is a possibility to restore the 77 GB of files and directories.

Thanks in advance
Thomas Piechocki

<Prev in Thread] Current Thread [Next in Thread>