0

Currently I believe I'm experiencing drive (HDD) failure. It is a single partition drive for extra storage. When I attempt to mount it I get the following error:

# mount /dev/sdc1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Checking dmesg as suggested:

# dmesg | tail
[12641.405658] blk_update_request: critical medium error, dev sdc, sector 2064
[12641.410139] Buffer I/O error on dev sdc1, logical block 2, async page read
[12641.415774] EXT4-fs (sdc1): couldn't mount as ext3 due to feature incompatibilities
[12641.420578] EXT4-fs (sdc1): couldn't mount as ext2 due to feature incompatibilities
[12644.186523] sd 5:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[12644.186543] sd 5:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current] 
[12644.186556] sd 5:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
[12644.186570] sd 5:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 08 10 00 00 08 00
[12644.186580] blk_update_request: critical medium error, dev sdc, sector 2064
[12644.191255] EXT4-fs (sdc1): can't read group descriptor 1

As I said, I'm assuming the drive is going night night, so I'd like to at least save whatever information I have on there (which is by the way more on the significant side). I tried chopping 500GB off the drive, just to see if it would work:

# ddrescue -d -s 500G /dev/sdc data.img data.log

Unfortunately I was running that over ssh and my pipe broke or something so I ended up with a ~150GB img file which when I try to mount I get the same error I got when trying to mount the drive itself (duh):

# mount data.img /mnt -o loop
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

How can I grab the information that is supposedly saved?

6
  • Try testdisk.
    – pLumo
    Jan 28 at 8:01
  • 1
    If the data is truly important, and you're not sure how to go about recovering it, a professional data recovery service is likely your best option.
    – Jim L.
    Jan 28 at 8:01
  • @JimL. the data is also private, so I'll have to do the best I can. I also believe that the drive has not failed to the point where only a professional would be able to restore the data from it, I just need a little help, because I'm a noob.
    – php_nub_qq
    Jan 28 at 12:41
  • @pLumo when I try to list the files on the partition testdisk reports Can't open filesystem. Filesystem seems damaged.
    – php_nub_qq
    Jan 28 at 12:48
  • Then you're probably out of luck to recover the drive as a whole and need to run some file recovery software, e.g. photorec can do a good job.
    – pLumo
    Jan 28 at 12:57

1 Answer 1

1

For anyone who finds this question, I managed to resolve the issue without resorting to photorec or other salvaging tools. I made a full disk image, just in case, using ddrescue but ended up not needing it.

Running badblocks and looking at SMART data I determined that there is 1 damaged sector which is somewhere in the beginning of the drive. Apparently it was where the superblock was stored and that's why the partition was not recognized and could not be mounted.

I tried running e2fsck -cfpv /dev/sdc1 and got

e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc1
Could this be a zero-length partition?

Me being the noob that I am I have no idea what's going on but apparently overwriting that sector with zeroes and re-running e2fsck does some kind of magic and fixed the partition, after which I was able to mount the partition and copy all my files before tossing that hdd out the window. Here are the commands I issued (Yes, I stopped e2fsck instantly once I noticed the partition is recognized and can be mounted):

# dd if=/dev/zero of=/dev/sdc1 bs=4096 count=1 seek=0
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000367146 s, 11.2 MB/s

# e2fsck -fy -b 32768 /dev/sdc1
e2fsck 1.46.2 (28-Feb-2021)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sdc1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
^C/dev/sdc1: e2fsck canceled.

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****

Full explanation and all credit goes to this guy to whom I wish the universe sends a good amount of health and wealth and fulfils his deepest desires!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.