0

I got an external drive that may need to be repaired.

When I try to mount it, I get the following error:

wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.

I have issues to repair the disk. I wanted to make a image copy of the disk before attempting any fsck repair. However making a image clone with dd takes 111 days for 300GB, and this is not an option:

dd if=/dev/input/DEVICE-HERE of=/dev/OUTPUT/DEVICE-HERE bs=64K conv=noerror,sync

This is the output from the dd command, and it is warning me that there is an error in the drive:

42598400 bytes (43 MB, 41 MiB) copied, 2035.41 s, 20.9 kB/s
42663936 bytes (43 MB, 41 MiB) copied, 2039 s, 20.9 kB/s
dd: error reading '/dev/sda1': Input/output error
437+214 records in
651+0 records out
42663936 bytes (43 MB, 41 MiB) copied, 2042.48 s, 20.9 kB/s
42991616 bytes (43 MB, 41 MiB) copied, 2048 s, 21.0 kB/s
dd: error reading '/dev/sda1': Input/output error
441+215 records in
656+0 records out
42991616 bytes (43 MB, 41 MiB) copied, 2051.39 s, 21.0 kB/s
43253760 bytes (43 MB, 41 MiB) copied, 2055 s, 21.0 kB/s
dd: error reading '/dev/sda1': Input/output error
444+216 records in
660+0 records out
43253760 bytes (43 MB, 41 MiB) copied, 2058.75 s, 21.0 kB/s
43581440 bytes (44 MB, 42 MiB) copied, 2062 s, 21.1 kB/s

Any suggestions?

3
  • Welcome to the site. Apart from the primary question, the block size in your dd command is rather small. You can improve the performance by choosing a larger block size (although 300 GB is large, of course).
    – AdminBee
    Apr 21 '20 at 10:30
  • 1
    Don't use dd for this. dd conv=noerror,sync corrupts data. Try ddrescue with min-read-rate instead. Apr 21 '20 at 10:34
  • 1
    I'm not sure your dd output necessarily indicates an error on the drive itself. Try the following command as root: smartctl -i /dev/sda or for lots more additional output smartctl -a /dev/sda And man smartctl will give you lots more info and options. Apr 21 '20 at 11:08
0

Baed on the info you provided, my best guess is that your disk is dying, or close to dead already.

If you have any important data inside, let DD do its work. Or there's always specialized companies that work on data recovery.

0
  1. first understand the disk setup and what filesystem it has on it to know what you are dealing with. First thing would be make sure it shows up properly in your BIOS/EFI upon computer boot and make use of any diagnostic at that level. You want to make sure the disk controller and connectors are all somewhat reliable and working. You don't want to make things harder by working with a bad SATA cable or bad connector, although that's likely not your problem. But you did mention external hard drive so I am assuming connected via USB. Ideally you would not want to mess with disks in this manner over USB because it can present some problems but that's another discussion; use good judgement and decide if it's worth removing the disk from the external enclosure to manually connect a SATA cable from it to your motherboard.

  2. Once running linux, make sure the disk shows up as a block device. Then make use of smartctl to run some cursory checks on the disk checking for anything obvious. Once here, you might be reasonably sure the hardware side of things is ok and your problem is data corruption related on the disk. You may run into some issues with smartctl over USB.

  3. Imagine not being able to read a book without being able to first read a correct table of contents. That's what the disk partition table is. Ideally you would want to have a backup copy of that which you could restore in the case the partition table got corrupted (most people do not do this). And it is here you would want to know if you had an MBR or GPT partition table, as well as the number of partitions and file systems that are on each.

wrong fs type, bad option, bad superblock

At this point is where you would run fsck to further diagnose the problem. Not every filesystem has a superblock but since your asking here at Unix & Linux I'm assuming an EXT3/4 file system. You can easily web search fixing bad superblock for more details than I care to type. In short: your mount fails because of a bad superblock 0 but there are many redundant copies located within the filesystem.

Recovering ext4 superblocks

And if you had an XFS file system, then you would want to begin by doing xfs_repair -n /dev/sda1 on it. But with fsck it is typically with the -b option on it to fix a bad superblock.

Here's a sample of many instructions you can find on the web: http://erikimh.com/linux-recover-corrupted-partition-from-a-bad-superblock/

I wanted to make a image copy of the disk before attempting any fsck repair... dd: error reading '/dev/sda1': Input/output error

so yes, a dd will do a complete bit for bit copy as a means of disaster prevention should you mess up. But then you have to manage a single 300GB file in your case which will likely present other problems. However the input/output error from dd indicates in my opinion a disk controller type of error and not necessarily data corruption that an fsck would fix. So back to #1 above and being mindful of USB.

If you take a brand new [good] disk and do a dd on it even before ever making a MBR or BPT partition table on it, it should work. To that point is why we [sometimes] do dd if=/dev/sda of=./mypartitiontable bs=512 count=1 to back up an MBR partition table for example which is located within the first 512 bytes of the disk, whether that partition table data is correct or not.

So if i had to guess based on the above dd input/output error you had or have some hardware'ish problem which also resulted in a corrupted partition table. You may be able to restore the corrupted superblock using fsck -b but you may also be working against some other hardware type problem which smartctl may indicate. You might also be able to make use of hdparm in troubleshooting. And be mindful of a USB connection to the disk, avoid that if possible.

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