The kernel-patch-xfs in the Debian archive is ancient. I have a newer home
brew I can post if you are interested. I don't know if that's the problem
though.
Regards,
Jeremy
----- Original Message -----
From: "Thomas Piechocki" <piechoc@xxxxxxxxxxx>
To: <linux-xfs@xxxxxxxxxxx>
Sent: Saturday, April 26, 2003 12:39 AM
Subject: Can't mount or repair new xfs-partition after recompiling kernel
> 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
>
>
>
|