Thanks very much Neil!
I never do anything forward thinking like mdadm —examine before
doing destructive things :). Unfortunately.
I couldn’t figure out how to make the offset work so I used
losetup -f --show -P /dev/sdac
which automatically creates:
/dev/loop0
/dev/loop0p1
/dev/loop0p2
/dev/loop0p3
/dev/loop0p4
/dev/loop0p5
/dev/loop0p6
/dev/loop0p7
/dev/loop0p7
/dev/loop0p8
But the errors are the same (below). No idea why it thinks
NTFS is involved. I’ll probably have to give up on
this and figure out how to get way better at backups because
my history of success with recovery once things get hosed
in some way is very poor.
[root@repo1 ~]# fsck.ext4 /dev/loop0p2
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_open2: Bad magic number in super-block
/sbin/e2fsck: Superblock invalid, trying backup blocks...
/sbin/e2fsck: Bad magic number in super-block while trying to open /dev/loop0p2
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
======
mount -o ro /dev/loop0p2 /mnt
Failed to mount '/dev/loop0p2': Invalid argument
The device '/dev/loop0p2' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
mount -o ro /dev/loop0p3 /mnt
NTFS signature is missing.
Failed to mount '/dev/loop0p3': Invalid argument
The device '/dev/loop0p3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
Regards,
—Ed
> On Apr 6, 2015, at 17:52, NeilBrown <neilb@xxxxxxx> wrote:
>
> On Mon, 6 Apr 2015 16:45:58 -0700 Eduard Rozenberg <eduardr@xxxxxxxxx> wrote:
>
>> Hello folks,
>>
>> I previously had the following setup:
>>
>> sda & sdb partitioned w/ GPT, 7 partitions each (usr, opt, var etc...)
>> 7 raid1’s with 2 devices for each pair of partitions (/dev/sda1 & /dev/sdab1, etc)
>> They’d been created under Slackware 13.37.
>>
>> I was trying to clean out mdadm from those partitions but keep the data so I ran
>> "mdadm --zero-superblock” on each of those previously RAID1 mdadm 1.2 ext4
>> partitions.
>
> The "1.2" metadata is stored 4k from the start of the device. The actual
> data is some megabytes further in. I don't suppose you still have the output
> of "mdadm --examine" from before you destroyed the superblocks??
>
>>
>> As a result I am now currently unable to mount any partition after the first one on either
>> disk. The first partition does mount. The partition table is visible and looks fine in gdisk.
>>
>> mount -t ext4 /dev/sdac2 /mnt
>> mount: wrong fs type, bad option, bad superblock on /dev/sdac2,
>> missing codepage or helper program, or other error
>> In some cases useful info is found in syslog - try
>> dmesg | tail or so
>>
>> I did try superblock recovery with each backup superblock that ext4 normally creates,
>> but none of the superblock locations worked.
>>
>> For example:
>>
>> fsck.ext4 -b 4096000 /dev/sdac2
>> e2fsck 1.42.8 (20-Jun-2013)
>> /sbin/e2fsck: Invalid argument while trying to open /dev/sdac2
>>
>> The superblock could not be read or does not describe a correct ext2
>> filesystem. If the device is valid and it really contains an ext2
>> filesystem (and not swap or ufs or something else), then the superblock
>> is corrupt, and you might try running e2fsck with an alternate superblock:
>> e2fsck -b 8193 <device>
>>
>>
>> Would be grateful for any advice on anything else I can try.
>
> You need to find where the filesystem actually starts, then you need to
> create some way to access it as a block device, then it should "just work".
>
> An ext4 filesystem superblock has 0xef53 at an offset of 0x38, and the
> superblock is typically 1K from the start of the partition.
>
> So you could:
> od -x /dev/sdac2 | awk '$6 == "ef53"'
>
> Then subtrace 0002060 (octal) from the leading number, and that might be the
> start of the partition.
>
> Then
> losetup -o "start in decimal" /dev/loop0 /dev/sdac2
>
> and try 'fsck' on /dev/loop0
>
> Good luck.
>
> NeilBrown
>
>
>
>>
>> Regards,
>> —Ed--
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
