I've had a series of different issues with recovering a RAID disk, ending with the error reported in the subject. Please skip the long story to come to the conclusions if you want.

Long story:

  • I set up an ubuntu server machine a couple of years ago with two 1TB disks in RAID1.
  • recently the machine was faulty and I dismantled it, taking the two HDD.
  • I managed to connect one of the disks to my laptop via USB and browse it correctly through mdadm.
  • Bought a Synology NAS and placed the other disk inside it, to create a new RAID system. Of course this way it was formatted and I had only one good disk with my old data.
  • Connected the good disk to the NAS via USB with the intent to copy all the old data to the freshly formatted disk inside the NAS. I managed to create a mdadm array in the NAS thanks to this guide http://forum.synology.com/wiki/index.php/How_to_manually_mount_a_USB_Hard_Disk,_including_a_disk_that_was_part_of_a_RAID1_array and managed to see that the disk had memory of its previous RAID configuration (in my laptop): mdadm --examine --scan /dev/sdk3 returned the line of information I expected
  • However the NAS at the end could not mount the disk (/dev/sdq1) to the filesystem (say /mnt/usb), with a generic "No such device" error. Apparently it seems mount in busybox (on which the NAS is based) is reluctant on giving further suggestions (http://www.silas.net.br/tech/linux/busybox-troubleshooting.html)
  • Then I thought "well, if I can't copy data via USB in the NAS I will connect the disk to my laptop and transfer trough ethernet". Good idea. Unfortunately, in the process of creating the array the NAS probably destroyed the original superblocks, so when I connected it to the laptop (Linux Mint ubuntu version) the partition showed up inside the file manager (mdadm worked fine and mapped the partition in /dev/mapper) but could not be mounted: raid mount: /dev/md1: can't read superblock
  • trying to fix with e2fsck didn't help
  • trying to fix with e2fsck -b didn't help
  • All the information were ok, like those in mdadm --examine --scan /dev/sdk3


  • I rebooted the laptop. Now the raid is not even assembled automatically by mdadm... I think the disk lost its UUID? Can it be? I see dmesg correctly connects the disk:

sd 7:0:0:0: [sdb] Attached SCSI disk

and a partition sdb1, but I cannot find the disk in /dev/disk/by-uuid

The RAID info is lost: mdadm --examine --scan /dev/sdk3 returns no information

  • Trying to manually create a new md returns: $ mdadm -A --verbose --run /dev/md3 /dev/sdb1 mdadm: looking for devices for /dev/md3 mdadm: no recogniseable superblock on /dev/sdb1 mdadm: /dev/sdb1 has no superblock - assembly aborted

I tried to restore a number of backup superblocks with:

e2fsck -b /dev/sdb1

e2fsck 1.42.9 (4-Feb-2014) e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

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

I got the superblock backup address with mke2fs -n /dev/sdb1

Is the disk totally fried??? Is it normally so that utilities overwrite important info on a disk and make it unusable?

Additional info:

$ fdisk -l /dev/sdb

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000

Device Boot Start End Blocks Id System /dev/sdb1 1 1953525167 976762583+ ee GPT

parted /dev/sdb

Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p
Model: SAMSUNG HD103SI (scsi) Disk /dev/sdb: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt

Number Start End Size File system Name Flags 1 17,4kB 1000GB 1000GB raid

1 Answer 1


With testdisk I realized that Linux RAID and Linux LVM2 partitioning were coexisting, so with testdisk I wrote the LVM partition table and I was able to mount the two ext3 partitions inside the disk.

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.