[makrospex]

Please try mount -t ext4 -o ro,offset=... /dev/md0p1 /mnt/md0 with offset values of 34*512 (and 35*512).
Make sure you are outside /mnt/md0 when mounting. Check contents of /mnt/md0 after mounting trials.

Code:

root@bitcorn:/# mount -t ext4 -o ro,offset=17408 /dev/md0p1 /mnt/md0
mount: /mnt/md0: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

root@bitcorn:/# mount -t ext4 -o ro,offset=17920 /dev/md0p1 /mnt/md0
mount: /mnt/md0: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

Would rather deal with you fine folks, here on these forums, than opening another thread on the Ubuntu forums. I intensely dislike creating more accounts than I have to.

For example, some dude from some registrar I don't use, wants to buy one of my domains from NetSol, and I'm all like "Fuck off, man. I don't want to create an account on your website. Rejecting your offer. Not for sale."

I'm a strange dude.

 

Being a "normal" dude would be way worse, imo 

I was misreading your last post in that support forum manner.

Please see if you have "testdisk" installed, or just *apt-get* (install) it. I'll point you to a quick guide so you can make yourself familiar what it does for you (as i will have to read up some pages too). You can examine disks/partitions, to get known to the program, just don't change/write anything yet.

[makrospex]

Interesting.

Found this, same problem, different configuration:

https://forum.cgsecurity.org/phpBB3/viewtopic.php?t=6446

All superblock backups failed for this user.
I'm reading further into it now...

[makrospex]

Strategy:

find valid superblocks using testdisk for use with e2fsck. Works in most cases, according to the internet.
In some cases, data can be read out directly with testdisk for backup.
But ultimately, lossless recovery is the goal.

EDIT:

https://forum.cgsecurity.org/phpBB3/viewtopic.php?t=34

Short version:

Code:

fsck.ext4 -y /dev/md127

Did the trick here. But please read the whole thing, since -y positively answers all fsck questions for confirmation of destructive changes.

[makrospex]

It's

/dev/md127

not

/dev/md0

this time.

EDIT: When the kernel fails to assemble a raid at /dev/md0, it places a spare at /dev/md127.
This results of raid failure, not uncommonly by errors in mdadm.conf.

If the fsck of md127 does not help getting it to mount, we will have to go over the mdadm.conf and identify the right ARRAY line to uncomment.
Most time it's a mismatch of UUID of the hdd and the config file.

[makrospex]

More bleh.

Came up as md127 upon a reboot.

Code:

root@bitcorn:/dev# mdadm --stop /dev/md127
mdadm: stopped /dev/md127
root@bitcorn:/dev# mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 3 drives.
root@bitcorn:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid5 sdb[0] sdd[2] sdc[1]
      7813772288 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>
root@bitcorn:/dev# dumpe2fs /dev/md0 | grep super
dumpe2fs 1.44.1 (24-Mar-2018)
dumpe2fs: Bad magic number in super-block while trying to open /dev/md0
Found a gpt partition table in /dev/md0
Couldn't find valid filesystem superblock.

Plan:
1. Reboot to make /dev/md127 reappear.
2. fsck -y /dev/md127
3. mount -t ext4 -o ro /dev/md127 /mnt/md0
4. check contents of /mnt/md0 directory

If it works, it either mounts as md0 at the next reboot, or we have to go into mdadm.conf checking/editing

EDIT: We don't lose hope. We lose things like (car)keys, memories and all our corn because of boating accidents 

[makrospex]

Plan:
1. Reboot to make /dev/md127 reappear.
2. fsck -y /dev/md127
3. mount -t ext4 -o ro /dev/md127 /mnt/md0
4. check contents of /mnt/md0 directory
If it works, it either mounts as md0 at the next reboot, or we have to go into mdadm.conf checking/editing
EDIT: We don't lose hope. We lose things like (car)keys, memories and all our corn because of boating accidents 

1. Rebooted. Came back as /dev/md0
2.

Code:

root@bitcorn:/# fsck -y /dev/md0
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md0

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
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>
 or
    e2fsck -b 32768 <device>

Found a gpt partition table in /dev/md0

3. Sheeeeeeeeeeeeeeeeeeeeeeeeeeeit.

Indeed 

Please paste the output of

Code:

mdadm --detail /dev/md0

[makrospex]

Shits fucked up reel gud now. No md arrays are showing up on reboot now.

Re-issuing mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd and going to bed. Will check again in the morning, but about ready to just say "fuck the array", lose mdadm altogether, and just having four separate disks in the system.

Bleh. Such bullshit.

 

sucks