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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .