Merited for the help. Not wasting any more time on it. Shit's fucked, yo.
Fucking mdadm...
Topic: (Read 575 times)
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.
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.
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. 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
or
e2fsck -b 32768
Found a gpt partition table in /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
or
e2fsck -b 32768
Found a gpt partition table in /dev/md0
3. Sheeeeeeeeeeeeeeeeeeeeeeeeeeeit.
Bleh. Starting to lose hope here.
Very frustrating to say the least.
Very frustrating to say the least.
Code:
root@bitcorn:/# fsck.ext4 -y /dev/md0
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
or
e2fsck -b 32768
Found a gpt partition table in /dev/md0
root@bitcorn:/# fsck.ext4 -y -b 32768 -B 4096 /dev/md0
e2fsck 1.44.1 (24-Mar-2018)
fsck.ext4: Filesystem revision too high while trying to open /dev/md0
The filesystem revision is apparently too high for this version of e2fsck.
(Or the filesystem superblock is corrupt)
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
or
e2fsck -b 32768
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
or
e2fsck -b 32768
Found a gpt partition table in /dev/md0
root@bitcorn:/# fsck.ext4 -y -b 32768 -B 4096 /dev/md0
e2fsck 1.44.1 (24-Mar-2018)
fsck.ext4: Filesystem revision too high while trying to open /dev/md0
The filesystem revision is apparently too high for this version of e2fsck.
(Or the filesystem superblock is corrupt)
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
or
e2fsck -b 32768
Please see if you have "testdisk" installed, or just *apt-get* (install) it.
Code:
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER
http://www.cgsecurity.org
Disk /dev/md0 - 8001 GB / 7451 GiB - CHS 1953443072 2 4
Current partition structure:
Partition Start End Size in sectors
Invalid RAID superblock
1 P Linux Raid 5118 15611104253 15611099136
1 P Linux Raid 5118 15611104253 15611099136
2 P Linux Swap 15611104256 15627541487 16437232
Christophe GRENIER
http://www.cgsecurity.org
Disk /dev/md0 - 8001 GB / 7451 GiB - CHS 1953443072 2 4
Current partition structure:
Partition Start End Size in sectors
Invalid RAID superblock
1 P Linux Raid 5118 15611104253 15611099136
1 P Linux Raid 5118 15611104253 15611099136
2 P Linux Swap 15611104256 15627541487 16437232
After running Quicksearch...
Code:
Disk /dev/md0 - 8001 GB / 7451 GiB - CHS 1953443072 2 4
Partition Start End Size in sectors
>P MS Data 5118 15611104253 15611099136
P Linux Swap 15611104256 15627541487 16437232
Partition Start End Size in sectors
>P MS Data 5118 15611104253 15611099136
P Linux Swap 15611104256 15627541487 16437232
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.
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.
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.
please try
and paste the output
EDIT: and the output from please
Code:
fsck -fCV /dev/md0p1
EDIT: and the output from
Code:
dmesg | grep md0
Code:
root@bitcorn:/mnt/md0# fsck -fCV /dev/md0p1
fsck from util-linux 2.31.1
[/sbin/fsck.ext2 (1) -- /dev/md0p1] fsck.ext2 -f -C0 /dev/md0p1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/md0p1
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
or
e2fsck -b 32768
root@bitcorn:/mnt/md0# dmesg | grep md0
[ 603.734416] md: md0 stopped.
[ 603.752297] md/raid:md0: device sdb operational as raid disk 0
[ 603.752298] md/raid:md0: device sdd operational as raid disk 2
[ 603.752298] md/raid:md0: device sdc operational as raid disk 1
[ 603.752538] md/raid:md0: raid level 5 active with 3 out of 3 devices, algorithm 2
[ 603.766207] md0: detected capacity change from 0 to 8001302822912
[ 603.771707] md0: p1 p2
[ 603.794854] EXT4-fs (md0): VFS: Can't find ext4 filesystem
[27284.994660] md0: p1 p2
[75034.851792] md0: p1 p2
[75312.365653] md0: p1 p2
[76336.491130] md0: p1 p2
[76355.758690] md0: p1 p2
At this point, it's become an Academic Exercise to fix this damned thing, and have this weirdo case documented somewhere on the internets, so it may help other folks who dun goofed as badly as I have.
Again, very grateful and appreciative for all of you dudes trying to help me out.
Just as some therapeutic exercise, could you post the output of
Code:
dumpe2fs -h /dev/md0p1
Code:
root@bitcorn:/mnt/md0# dumpe2fs -h /dev/md0p1
dumpe2fs 1.44.1 (24-Mar-2018)
dumpe2fs: Bad magic number in super-block while trying to open /dev/md0p1
Couldn't find valid filesystem superblock.
can you please paste the output of
Code:
parted --list
Code:
root@bitcorn:/mnt/md0# parted --list
Model: ATA WDC WD40EFRX-68N (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 EFI System Partition boot, esp
2 538MB 3992GB 3992GB ext4
3 3992GB 4001GB 8417MB linux-swap(v1)
Error: The primary GPT table is corrupt, but the backup appears OK, so that will
be used.
OK/Cancel? ^C
Model: ATA WDC WD40EFRX-68N (scsi)
Disk /dev/sdb: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
Error: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
OK/Cancel? ^C
Model: ATA WDC WD40EFRX-68N (scsi)
Disk /dev/sdc: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
Error: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
OK/Cancel? ^C
Model: ATA WDC WD40EFRX-68N (scsi)
Disk /dev/sdd: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
Model: Linux Software RAID Array (md)
Disk /dev/md0: 8001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 2620kB 7993GB 7993GB raid
2 7993GB 8001GB 8416MB linux-swap(v1)
root@bitcorn:/mnt/md0#
CTRL-C'd through all the prompts.
There may be a wallet.dat on that volume - likely containing dust, but would like to confirm. Best I know, I moved all the corn I had on that system back to my wallet.
Also, really don't want to resync since genesis block.
EDIT: Typing "OK" during the parted --list did nothing either.
Otherwise I am bit confused about the loop part still, did you by chance have for example an encrypted filesystem on top of that raid device?
Code:
root@bitcorn:/mnt/md0# fsck.ext4 -b 32768 /dev/md0p1
e2fsck 1.44.1 (24-Mar-2018)
fsck.ext4: Bad magic number in super-block while trying to open /dev/md0p1
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
or
e2fsck -b 32768
No encrypted filesystems at all.
At least there are valid superblock backups, that's a start I guess.
Please try the mounts with the device I suggested above and not /dev/md0:
i.e.
Please try the mounts with the device I suggested above and not /dev/md0:
i.e.
Code:
mount -t ext4 -o ro,offset=32768 /dev/md0p1 /mnt/md0
Code:
root@bitcorn:/mnt/md0# mount -t ext4 -o ro,offset=32768 /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.
from mke2fs: /dev/md0p1 alignment is offset by 1024 bytes.
This may result in very poor performance, (re)-partitioning suggested.
Might that have something to do with it ? Add 1024 to whatever the offsets say ?
Regarding the mounts to try from makrospex, please try these again with /dev/md0p1 instead of /dev/md0, i.e.:
Maybe also check that /mnt/md0 is empty, otherwise the mount might fail with a slightly different error message that you could overlook easily.
Code:
mount -t ext4 -o=ro,offset xxx /dev/md0p1 /mnt/md0
Ok. Think we might be getting somewhere now ?
Code:
root@bitcorn:/dev# mke2fs -n /dev/md0p1
mke2fs 1.44.1 (24-Mar-2018)
/dev/md0p1 alignment is offset by 1024 bytes.
This may result in very poor performance, (re)-partitioning suggested.
Creating filesystem with 1951387392 4k blocks and 243924992 inodes
Filesystem UUID: dfa782b3-06dc-4e04-959e-ac535a95b727
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632
root@bitcorn:/dev# mount -t ext4 -o ro,offset=32768 /dev/md0 /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:/dev# mount -t ext4 -o ro,offset=98304 /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:/dev# mount -t ext4 -o ro,offset=163840 /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.
LOL. Nope.
/mnt/md0 is indeed empty
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.
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
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. 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
or
e2fsck -b 32768
Found a gpt partition table in /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
or
e2fsck -b 32768
Found a gpt partition table in /dev/md0
3. Sheeeeeeeeeeeeeeeeeeeeeeeeeeeit.
Indeed
Please paste the output of
Code:
mdadm --detail /dev/md0
More bleh.
Came up as md127 upon a reboot.
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:
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.
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:
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
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.
/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.
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:
Did the trick here. But please read the whole thing, since -y positively answers all fsck questions for confirmation of destructive changes.
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.
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...
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...
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.
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.
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.
This took a little longer, since i had to back/crossread and type a reply in a text editor, not to lose overview (cause of my impaired working memory ya'll might know already about). Here we go:
This means the start of md0p1 is not at the start of a physical sector (multiple of 4096 bytes).
It's not a cause for failure.
compare to this:
root@bitcorn:/dev# sgdisk -p /dev/md0
Disk /dev/md0: 15627544576 sectors, 7.3 TiB
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15627544542
Partitions will be aligned on 8-sector boundaries
Total free space is 8141 sectors (4.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 5118 15611104253 7.3 TiB FD00
2 15611104256 15627541487 7.8 GiB 8200
The partition should start at sector mulitple of 8, but starts at 34, because the partition table takes up 33 sectors.
So it's 2 sectors (each 512 bytes) = 1024 bytes "behind" of the optimum (or 6 sectors in front). Would have been better to start at sector 40, forexample.
There are unused sectors at the end of the disk, meaning this is a GPT partition (in contrast to classic MBR).
Strangely, the GUID of the drive is zero (00000000-0000-0000-0000-000000000000), but that might not be important, too.
Also strange is the fact that the table lists 5118 as starting sector of md0p1, instead of 34.
Partition 2 (md0p2) starts at 15611104256, which is a multiple of 8, thus PERFECT.
When calculating the length of md0p1, its 2 sectors short of a multiple of 8.
Conclusion: Like suggests,
The superblock backup positions from are for , not for mount.
Since the master partition table seems to be invalid, we can't calculate a valid offset for mount, because we don't know the correct starting sector yet.
The solution to these might be found in the backup partition table too.
An ext4 superblock has a size of 1024 bytes. coincidence?
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.
Then issue a
e2fsck -b some_backup_block_numbers_from_mke2fs /dev/md0p1
preferably using the higher backup superblock numbers.
The blocksize would be good to know exactly, while it defaults to 4096.
Next shot would be using "testdrive" in non-destructive mode, to find out more details about the partitions of md0 and values like real start, end, blocksize of md0p1
Even to restore it all completely by testdisk logs manually.
If you want to put up a thread in an expert forum (the community support forum of your linux distribution, i'd suggest) please link it here, so we can follow and give further assistance, raise our cups when solved, or whatever
EDIT:
Advice: I was avoiding raid arrays most of the time, because if you got trouble with them beyond anything a rebuild/resync can handle, you're going to face problems in the higher PITA levels. Either the disks/partitions are not readable after the raid controller died and you have no backup hardware at hand, or in case of software raid, you can't just mount the raid sub-partitions and read them easily. I went to single drives (ssd for performance) and frequent backups just NOT to rely on raid whenever possible.
Backup is uncomfortable, takes a lot of storage but also somehow inevitable. Sorry for the pain. I hope you have a key/seed backup for the wallet and the blockchain sync does not take forever if you set up a new node. If you didn't do already, DISABLE the f**ing green power saving functions of any hard drive you use, these lead to parking the heads much more often, spinning down drives too soon, which puts stress on the hardware and kills drives sooner (which adds to the electronic waste problem, thus anything but "green"). I disabled this on all my "green" WDC 2TB drives in my NAS, after i saw one failing after half a year because of that).
Quote
/dev/md0p1 alignment is offset by 1024 bytes.
This means the start of md0p1 is not at the start of a physical sector (multiple of 4096 bytes).
It's not a cause for failure.
compare to this:
Quote
root@bitcorn:/dev# sgdisk -p /dev/md0
Disk /dev/md0: 15627544576 sectors, 7.3 TiB
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15627544542
Partitions will be aligned on 8-sector boundaries
Total free space is 8141 sectors (4.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 5118 15611104253 7.3 TiB FD00
2 15611104256 15627541487 7.8 GiB 8200
The partition should start at sector mulitple of 8, but starts at 34, because the partition table takes up 33 sectors.
So it's 2 sectors (each 512 bytes) = 1024 bytes "behind" of the optimum (or 6 sectors in front). Would have been better to start at sector 40, forexample.
There are unused sectors at the end of the disk, meaning this is a GPT partition (in contrast to classic MBR).
Strangely, the GUID of the drive is zero (00000000-0000-0000-0000-000000000000), but that might not be important, too.
Also strange is the fact that the table lists 5118 as starting sector of md0p1, instead of 34.
Partition 2 (md0p2) starts at 15611104256, which is a multiple of 8, thus PERFECT.
When calculating the length of md0p1, its 2 sectors short of a multiple of 8.
Conclusion: Like
Code:
parted --list
Quote
Error: The primary GPT table is corrupt, but the backup appears OK, so that will
be used.
the Partition table is corrupted. I'll read up how to handle this after this post.be used.
The superblock backup positions from
Code:
mke2fs -n ...
Code:
fsck -t ext4 -b
Since the master partition table seems to be invalid, we can't calculate a valid offset for mount, because we don't know the correct starting sector yet.
The solution to these might be found in the backup partition table too.
An ext4 superblock has a size of 1024 bytes. coincidence?
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.
Then issue a
e2fsck -b some_backup_block_numbers_from_mke2fs /dev/md0p1
preferably using the higher backup superblock numbers.
The blocksize would be good to know exactly, while it defaults to 4096.
Next shot would be using "testdrive" in non-destructive mode, to find out more details about the partitions of md0 and values like real start, end, blocksize of md0p1
Even to restore it all completely by testdisk logs manually.
If you want to put up a thread in an expert forum (the community support forum of your linux distribution, i'd suggest) please link it here, so we can follow and give further assistance, raise our cups when solved, or whatever
EDIT:
Advice: I was avoiding raid arrays most of the time, because if you got trouble with them beyond anything a rebuild/resync can handle, you're going to face problems in the higher PITA levels. Either the disks/partitions are not readable after the raid controller died and you have no backup hardware at hand, or in case of software raid, you can't just mount the raid sub-partitions and read them easily. I went to single drives (ssd for performance) and frequent backups just NOT to rely on raid whenever possible.
Backup is uncomfortable, takes a lot of storage but also somehow inevitable. Sorry for the pain. I hope you have a key/seed backup for the wallet and the blockchain sync does not take forever if you set up a new node. If you didn't do already, DISABLE the f**ing green power saving functions of any hard drive you use, these lead to parking the heads much more often, spinning down drives too soon, which puts stress on the hardware and kills drives sooner (which adds to the electronic waste problem, thus anything but "green"). I disabled this on all my "green" WDC 2TB drives in my NAS, after i saw one failing after half a year because of that).
Jump to: