I'm attempting to extract data from a HD that has a bunch of linux-raid partitions, including one large one with data I need to save off the disk.
I actually have two drives like that (both not from the same RAID pair), and one of them I was successful in creating a MD device so I could mount it RO and copy off a ton of data.
the second one fails to mount, saying the XFS filesystem is corrupted. Attempting to run XFS_repair I get a message that the filesystem is XFS-1 and I need an older version of XFS tools to do it.
I'm running Centos-7 with whatever version of XFS tools comes with it, according to 'yum list installed' it appears to be xfsprogs 4.5.0-22.el7.
I don't particularly want to install another, older, version of xfsprogs on this system. can anyone suggest any other way to gain access to this disk partition?
Thanks in advance!
Fred
You could try downloading an ISO of knoppix, and boot from that with the drive installed, and use the xfs_repair tools from there without having to install other tools on the drive in question.
On 11/23/2021 8:45 AM, Fred wrote:
I'm attempting to extract data from a HD that has a bunch of linux-raid partitions, including one large one with data I need to save off the disk.
I actually have two drives like that (both not from the same RAID pair), and one of them I was successful in creating a MD device so I could mount it RO and copy off a ton of data.
the second one fails to mount, saying the XFS filesystem is corrupted. Attempting to run XFS_repair I get a message that the filesystem is XFS-1 and I need an older version of XFS tools to do it.
I'm running Centos-7 with whatever version of XFS tools comes with it, according to 'yum list installed' it appears to be xfsprogs 4.5.0-22.el7.
I don't particularly want to install another, older, version of xfsprogs on this system. can anyone suggest any other way to gain access to this disk partition?
Thanks in advance!
Fred _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi,
I'm attempting to extract data from a HD that has a bunch of linux-raid partitions, including one large one with data I need to save off the disk.
I actually have two drives like that (both not from the same RAID pair), and one of them I was successful in creating a MD device so I could mount it RO and copy off a ton of data.
the second one fails to mount, saying the XFS filesystem is corrupted. Attempting to run XFS_repair I get a message that the filesystem is XFS-1 and I need an older version of XFS tools to do it.
Are you sure the filesystem is really corrupt? Maybe it's only your kernel which doesn't understand the old XFS version?
To use older xfs_repair, you can just download an older version like xfsprogs-2.9.4-1.el4.centos.x86_64.rpm, extract it to a directory and call the xfs_repair binary from the package.
I'm not sure whether you need a matching xfs kernel module to run xfs_repair successfully.
Regards, Simon
I'll take a look at these two ideas soon. Thanks!
On Tue, Nov 23, 2021 at 10:03 AM Simon Matter simon.matter@invoca.ch wrote:
Hi,
I'm attempting to extract data from a HD that has a bunch of linux-raid partitions, including one large one with data I need to save off the
disk.
I actually have two drives like that (both not from the same RAID pair), and one of them I was successful in creating a MD device so I could mount it RO and copy off a ton of data.
the second one fails to mount, saying the XFS filesystem is corrupted. Attempting to run XFS_repair I get a message that the filesystem is XFS-1 and I need an older version of XFS tools to do it.
Are you sure the filesystem is really corrupt? Maybe it's only your kernel which doesn't understand the old XFS version?
To use older xfs_repair, you can just download an older version like xfsprogs-2.9.4-1.el4.centos.x86_64.rpm, extract it to a directory and call the xfs_repair binary from the package.
I'm not sure whether you need a matching xfs kernel module to run xfs_repair successfully.
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
haven't tried the suggestions yet, but here is some diagnostics on what happens when I attempt to mount it: upon running *mdadm --assemble /dev/md40 /mnt/dvd --run*, info from /var/log/messages): (note that /mnt/dvd is just an empty mount point that exists, used here for convenience).
Nov 24 12:21:42 fcshome kernel: md: md40 stopped. Nov 24 12:21:42 fcshome kernel: md/raid1:md40: active with 1 out of 2 mirrors Nov 24 12:21:42 fcshome kernel: md40: detected capacity change from 0 to 996887429120
output from doing: sudo mount /dev/md40 /mnt/dvd mount: mount /dev/md40 on /mnt/dvd failed: Structure needs cleaning
corresponding items from /var/log/messages: Nov 24 12:22:55 fcshome kernel: XFS (md40): Superblock earlier than Version 5 has XFS_[PQ]UOTA_{ENFD|CHKD} bits. Nov 24 12:22:55 fcshome kernel: XFS (md40): Metadata corruption detected at xfs_sb_read_verify+0x122/0x160 [xfs], xfs_sb block 0xff ffffffffffffff Nov 24 12:22:55 fcshome kernel: XFS (md40): Unmount and run xfs_repair Nov 24 12:22:55 fcshome kernel: XFS (md40): First 128 bytes of corrupted metadata buffer: Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0000: 58 46 53 42 00 00 10 00 00 00 00 00 0e 81 b1 e0 XFSB............ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0020: d2 22 a7 30 dd 88 48 8b bd bb 9c 8b 2a 22 72 cc .".0..H.....*"r. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0030: 00 00 00 00 08 00 00 04 00 00 00 00 00 00 00 80 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0050: 00 00 00 01 00 74 0d 8f 00 00 00 20 00 00 00 00 .....t..... .... Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0060: 00 00 80 00 30 c4 02 00 01 00 00 10 00 00 00 00 ....0........... Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0070: 00 00 00 00 00 00 00 00 0c 09 08 04 17 00 00 19 ................ Nov 24 12:22:55 fcshome kernel: XFS (md40): SB validate failed with error -117.
running xfs_repair give: sudo xfs_repair /dev/md40 Phase 1 - find and verify superblock... xfs_repair: V1 inodes unsupported. Please try an older xfsprogs.
before proceeding with other experiments, I decided to use dd to create an image file on my local disk of that partition so I could mess with it with less chance of trashing the on-disk partition. when attempting to use it, I get:
sudo mdadm --assemble /dev/md41 ./part4.img --run mdadm: ./part4.img is not a block device. mdadm: ./part4.img has no superblock - assembly aborted
So, I thought maybe the image had somehow become corrupted, so I did:
sudo md5sum /dev/sdd4 bd7cac3c886e7b3110e28100e119bb82 /dev/sdd4
and
md5sum part4.img bd7cac3c886e7b3110e28100e119bb82 part4.img
which shows the partition and its disk image to be identical.
Why shouldn't a dd image of a partition work just as well (for my purposes) as the actual disk partition? I've certainly done this before with EXTn and NTFS filesystems, is XFS somehow different in this regard?
Do any of you know what I'm doing wrong here?
Thanks in advance!
Fred
On Tue, Nov 23, 2021 at 3:57 PM Fred fred.fredex@gmail.com wrote:
I'll take a look at these two ideas soon. Thanks!
On Tue, Nov 23, 2021 at 10:03 AM Simon Matter simon.matter@invoca.ch wrote:
Hi,
I'm attempting to extract data from a HD that has a bunch of linux-raid partitions, including one large one with data I need to save off the
disk.
I actually have two drives like that (both not from the same RAID pair), and one of them I was successful in creating a MD device so I could
mount
it RO and copy off a ton of data.
the second one fails to mount, saying the XFS filesystem is corrupted. Attempting to run XFS_repair I get a message that the filesystem is
XFS-1
and I need an older version of XFS tools to do it.
Are you sure the filesystem is really corrupt? Maybe it's only your kernel which doesn't understand the old XFS version?
To use older xfs_repair, you can just download an older version like xfsprogs-2.9.4-1.el4.centos.x86_64.rpm, extract it to a directory and call the xfs_repair binary from the package.
I'm not sure whether you need a matching xfs kernel module to run xfs_repair successfully.
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
haven't tried the suggestions yet, but here is some diagnostics on what happens when I attempt to mount it: upon running *mdadm --assemble /dev/md40 /mnt/dvd --run*, info from /var/log/messages): (note that /mnt/dvd is just an empty mount point that exists, used here for convenience).
Nov 24 12:21:42 fcshome kernel: md: md40 stopped. Nov 24 12:21:42 fcshome kernel: md/raid1:md40: active with 1 out of 2 mirrors Nov 24 12:21:42 fcshome kernel: md40: detected capacity change from 0 to 996887429120
output from doing: sudo mount /dev/md40 /mnt/dvd mount: mount /dev/md40 on /mnt/dvd failed: Structure needs cleaning
corresponding items from /var/log/messages: Nov 24 12:22:55 fcshome kernel: XFS (md40): Superblock earlier than Version 5 has XFS_[PQ]UOTA_{ENFD|CHKD} bits. Nov 24 12:22:55 fcshome kernel: XFS (md40): Metadata corruption detected at xfs_sb_read_verify+0x122/0x160 [xfs], xfs_sb block 0xff ffffffffffffff Nov 24 12:22:55 fcshome kernel: XFS (md40): Unmount and run xfs_repair Nov 24 12:22:55 fcshome kernel: XFS (md40): First 128 bytes of corrupted metadata buffer: Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0000: 58 46 53 42 00 00 10 00 00 00 00 00 0e 81 b1 e0 XFSB............ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0020: d2 22 a7 30 dd 88 48 8b bd bb 9c 8b 2a 22 72 cc .".0..H.....*"r. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0030: 00 00 00 00 08 00 00 04 00 00 00 00 00 00 00 80 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0050: 00 00 00 01 00 74 0d 8f 00 00 00 20 00 00 00 00 .....t..... .... Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0060: 00 00 80 00 30 c4 02 00 01 00 00 10 00 00 00 00 ....0........... Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0070: 00 00 00 00 00 00 00 00 0c 09 08 04 17 00 00 19 ................ Nov 24 12:22:55 fcshome kernel: XFS (md40): SB validate failed with error -117.
running xfs_repair give: sudo xfs_repair /dev/md40 Phase 1 - find and verify superblock... xfs_repair: V1 inodes unsupported. Please try an older xfsprogs.
before proceeding with other experiments, I decided to use dd to create an image file on my local disk of that partition so I could mess with it with less chance of trashing the on-disk partition. when attempting to use it, I get:
sudo mdadm --assemble /dev/md41 ./part4.img --run mdadm: ./part4.img is not a block device. mdadm: ./part4.img has no superblock - assembly aborted
So, I thought maybe the image had somehow become corrupted, so I did:
sudo md5sum /dev/sdd4 bd7cac3c886e7b3110e28100e119bb82 /dev/sdd4
and
md5sum part4.img bd7cac3c886e7b3110e28100e119bb82 part4.img
which shows the partition and its disk image to be identical.
Why shouldn't a dd image of a partition work just as well (for my purposes) as the actual disk partition? I've certainly done this before with EXTn and NTFS filesystems, is XFS somehow different in this regard?
Do any of you know what I'm doing wrong here?
I'm not sure but I think you are making it too complicated.
If the partition is from a software RAID 1, then you should be able to use it directly without building an mdadm array.
That said, it depends on the metadata type IIRC. If metadata is in the beginning of the partition, then you have to remove it by doing a dd to a file and skipping the metadata in the beginning of the partition.
md raid metadata locations: 0.9 At the end of the device 1.0 At the end of the device 1.1 At the beginning of the device 1.2 4K from the beginning of the device
So with metadata versions 0.9 0r 1.0, you could directly use the md partition like a normal partition, only some bytes in the end are not used by the filesystem.
Regards, Simon
Ah HA! I b elieve I saw in a dump somewhere that it was 0.9. so I should be off to the races!
Thanks!
Fred
On Wed, Nov 24, 2021 at 1:14 PM Simon Matter simon.matter@invoca.ch wrote:
haven't tried the suggestions yet, but here is some diagnostics on what happens when I attempt to mount it: upon running *mdadm --assemble /dev/md40 /mnt/dvd --run*, info from /var/log/messages): (note that /mnt/dvd is just an empty mount point that exists, used here for convenience).
Nov 24 12:21:42 fcshome kernel: md: md40 stopped. Nov 24 12:21:42 fcshome kernel: md/raid1:md40: active with 1 out of 2 mirrors Nov 24 12:21:42 fcshome kernel: md40: detected capacity change from 0 to 996887429120
output from doing: sudo mount /dev/md40 /mnt/dvd mount: mount /dev/md40 on /mnt/dvd failed: Structure needs cleaning
corresponding items from /var/log/messages: Nov 24 12:22:55 fcshome kernel: XFS (md40): Superblock earlier than Version 5 has XFS_[PQ]UOTA_{ENFD|CHKD} bits. Nov 24 12:22:55 fcshome kernel: XFS (md40): Metadata corruption detected at xfs_sb_read_verify+0x122/0x160 [xfs], xfs_sb block 0xff ffffffffffffff Nov 24 12:22:55 fcshome kernel: XFS (md40): Unmount and run xfs_repair Nov 24 12:22:55 fcshome kernel: XFS (md40): First 128 bytes of corrupted metadata buffer: Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0000: 58 46 53 42 00 00 10 00 00 00 00 00 0e 81 b1 e0 XFSB............ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0020: d2 22 a7 30 dd 88 48 8b bd bb 9c 8b 2a 22 72 cc .".0..H.....*"r. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0030: 00 00 00 00 08 00 00 04 00 00 00 00 00 00 00 80 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 ................ Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0050: 00 00 00 01 00 74 0d 8f 00 00 00 20 00 00 00 00 .....t..... .... Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0060: 00 00 80 00 30 c4 02 00 01 00 00 10 00 00 00 00 ....0........... Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0070: 00 00 00 00 00 00 00 00 0c 09 08 04 17 00 00 19 ................ Nov 24 12:22:55 fcshome kernel: XFS (md40): SB validate failed with error -117.
running xfs_repair give: sudo xfs_repair /dev/md40 Phase 1 - find and verify superblock... xfs_repair: V1 inodes unsupported. Please try an older xfsprogs.
before proceeding with other experiments, I decided to use dd to create
an
image file on my local disk of that partition so I could mess with it
with
less chance of trashing the on-disk partition. when attempting to use it, I get:
sudo mdadm --assemble /dev/md41 ./part4.img --run mdadm: ./part4.img is not a block device. mdadm: ./part4.img has no superblock - assembly aborted
So, I thought maybe the image had somehow become corrupted, so I did:
sudo md5sum /dev/sdd4 bd7cac3c886e7b3110e28100e119bb82 /dev/sdd4
and
md5sum part4.img bd7cac3c886e7b3110e28100e119bb82 part4.img
which shows the partition and its disk image to be identical.
Why shouldn't a dd image of a partition work just as well (for my purposes) as the actual disk partition? I've certainly done this before with EXTn and NTFS filesystems, is XFS somehow different in this regard?
Do any of you know what I'm doing wrong here?
I'm not sure but I think you are making it too complicated.
If the partition is from a software RAID 1, then you should be able to use it directly without building an mdadm array.
That said, it depends on the metadata type IIRC. If metadata is in the beginning of the partition, then you have to remove it by doing a dd to a file and skipping the metadata in the beginning of the partition.
md raid metadata locations: 0.9 At the end of the device 1.0 At the end of the device 1.1 At the beginning of the device 1.2 4K from the beginning of the device
So with metadata versions 0.9 0r 1.0, you could directly use the md partition like a normal partition, only some bytes in the end are not used by the filesystem.
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Christopher Wensink -
Fred -
Simon Matter