Can't mount HDD dock

[coffee412]

COOL.

Raid /dev/md127 is active and degraded probably.

Lets just take a quick look at /dev/md127:

Code: Select all

sudo mdadm --detail /dev/md127 

Now we know how the raid was setup in the other system before the nas failed. Here is the layout of your old nas - Each partition on the drive(s) was mirrored to provide a bootable raid1 (mirroring). So, Each drive had mirrored partitions. As you can see, The raid devices (/dev/md*) are all active but probably in a degraded state. This means a drive in each array is missing. We can expect this as we are only working with one drive. This makes perfect sense. The reason we could not mount an individual partition (shows as busy) is because it belongs to a raid and the raid is active - thus the drive will be busy.

So, Now all we have to do is make sure we have somewhere to mount the degraded raid - with the correct device number (/dev/md127) and pull your data off it.

Lets first make sure you have somewhere to mount it.

Code: Select all

sudo mkdir /mnt/recovery

Now lets get this thing mounted.

Code: Select all

sudo mount -t ext4 /dev/md127 /mnt/recovery

I am assuming its a ext4 formatted partition. If its really old it could be ext3 but doubt it.

After the above mount command works then lets take a look at what is on the drive.

Code: Select all

ls /mnt/recovery

Let me know if it mounts. It should unless there is file damage. If there is some file damage we can fix that pretty quick

Let me know ......

[jpete]

Code: Select all

sudo mdadm --detail /dev/md127 
[sudo] password for jeff: 
/dev/md127:
        Version : 0.90
  Creation Time : Sun Jul 24 23:01:59 2011
     Raid Level : raid1
     Array Size : 1943479360 (1853.45 GiB 1990.12 GB)
  Used Dev Size : 1943479360 (1853.45 GiB 1990.12 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 127
    Persistence : Superblock is persistent

    Update Time : Wed Mar  1 19:22:26 2017
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       19        1      active sync

Code: Select all

sudo mount -t ext4 /dev/md127 /mnt/recovery
mount: wrong fs type, bad option, bad superblock on /dev/md127,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

[coffee412]

Lets see if we can mount it with instead the 'auto' in place of the ext4.

Also, Fire up the program menu/accessories/disks and click on the partition then post the pick - Want to see how its formatted out.

Code: Select all

sudo mount -t auto /dev/md127 /mnt/recovery

[coffee412]

Be sure to click on the actual raid device md127 so we can see what format it is in 'disks'

[jpete]

Code: Select all

sudo mount -t auto /dev/md127 /mnt/recovery
[sudo] password for jeff: 
mount: /dev/md127: can't read superblock

Not sure why it is reading 2 arrays with different sizes?

Also, sorry about the screen shots. I haven't figured out how to work with GIMP yet.

[coffee412]

The reason for the different size raids is because you have to look at it like this:

You have a boot partition - which is your first partition on a drive. In our case /dev/sdb1
You then probably have a UEFI partition which is /dev/sdb2
Then you have a root partition which is your whole operating system which is /dev/sdb3

Well, Each partition is mirrored to another drive. So, Your boot, UEFI, root are actually 3 different raids. They are numbered as you can see like md127, md126,md125 ect...

The reason we cannot get it mounted is because its using the older ext3 formatting - not the current ext4 that you normally find.

EDIT:
Lets do this instead.
Lets try and recover the superblocks on the drive. Lets see if any show up. Obviously this partition is a bit screwed up. But we have backup superblocks to work with. Lets find them first.

Code: Select all

sudo dumpe2fs /dev/md127 | grep superblock

Please post the output of this.

[jpete]

Code: Select all

sudo dumpe2fs /dev/md127 | grep superblock
[sudo] password for jeff: 
dumpe2fs 1.42.9 (4-Feb-2014)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/md127
Couldn't find valid filesystem superblock.

[coffee412]

For some reason your superblocks (which store info on the file system) are not showing up. This is strange. Lets try this:

mke2fs -n /dev/md127

Post the output of this and lets see what we get.

coffee

[jpete]

Code: Select all

sudo mke2fs -n /dev/md127
[sudo] password for jeff: 
mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
121470976 inodes, 485869840 blocks
24293492 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
14828 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848

[coffee412]

Weird that we now have some superblocks. Must be damaged file system. Thats possibly why it will not mount. So, Lets clean up the file system and then try and mount it.

Code: Select all

 sudo fsck -b 32768 /dev/md127

After that finishes, Lets try and mount it again.

Code: Select all

sudo mount -t ext3 /dev/md127 /mnt/recovery

did it work?

[jpete]

Code: Select all

sudo fsck -b 32768 /dev/md127
[sudo] password for jeff: 
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/md127
Could this be a zero-length partition?

[coffee412]

Ok, I will post back with more info later today ( Iam EST). I have to swap out my server/firewall to another system and this is going to take a few hours. Ill post back later today.

Keep the faith

coffee

[jpete]

No problem. I'm east of you so we're in the same time zone.

[coffee412]

Ok, I just got my server moved to a new system and I am back on line.

Lets try this:

Code: Select all

sudo e2fsck -f -b 32768 -y /dev/md127

[jpete]

Code: Select all

sudo e2fsck -f -b 32768 -y /dev/md127
[sudo] password for jeff: 
e2fsck 1.42.9 (4-Feb-2014)
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/md127
Could this be a zero-length partition?

[coffee412]

Jeff,

Iam beginning to think this drive has some serious damage to it hardware wise. Like some pretty bad sectors. Pretty much what I have covered should have made it mountable. If the drive is physically damaged then we are not going to make it. Therefore, Lets backup a bit and resolve the health of this particular drive.

To my understanding this drive is hooked up to a USB connection. Im thinking its usb2. USB2 does not support checking the drive health. USB3 does and so does SATA and eSATA.

If you have a USB3 port you can hook this drive into then lets do that. Otherwise, Perhaps a sata cable connected to the motherboard can be used and you can boot up normally.

Then go into disks (menu/accessories/disks) and run a smart test on the drive. My thinking is that we should not pound our heads any further if the drive is actually physically damaged. Lets just prove the drive does not have tons of bad sectors or whatever.

If the drive has a lot of damage we might be able to do something else - clone the degraded raid after its active to a known good drive the same size as the partition or bigger.

So, Lets backup here and take a look at the drive and run the short test in disks to see how it stands. If there is damage then its going to change our focus to recovery of files. Besides, A bad disk can be preventing us from mounting it.

Post your output once you run the smart test so I can see what is going on. If the smart test is greyed out then that is because you are on a usb2 connection or your usb3 for a weird reason does not support it. I know that my new ASUS x370 pro board does support smart tests thru usb3. Hopefully yours does if you have usb3 if not then hook this drive up via a sata port.

Sound good?

coffee

[coffee412]

BTW --- Use 'screenshot' for your pics. It works very well. --- menu/accessories/take screenshot

Check the individual drive (/dev/sdb) not the raid.

[jpete]

Not sure I can do what you suggest. My laptop doesn't have USB 3.0 ports, just on e-sata port. The drive dock is USB 3.0.

I will have to get a cable to hook it up like that. Right now, I have it plugged into a USB 2.0 port on the computer.

And my desktop computer is an even bigger train wreck than my laptop.

I can't even get that thing to boot at all.

I'll see if I can track down a cable tomorrow and do what you suggested.

Thanks!

[jpete]

Did a little research and found that the cable doesn't work "backward" so I found an express card for the laptop that has USB 3.0 slots. Should arrive by Tuesday so I will try again then.

[coffee412]

No problem Jeff

Well, Tonite my firewall server took a big dump and Im connected via my surf box. Kinda unprotected at the moment. I have to sort some junk out on the server

See you then tuesday or whatever

I bet we find that drive is damaged somehow with bad sectors or whatever. Dont mean to sound pessimistic but we should have been able to get somewhere with it by now. We will see though

coffee