I have four 500GB disks which were set up as a Linux Software-RAID 5 volume during the Debian install (next to the system drive which is a SSD). One of the drives (sda) went bad and now I am trying to replace it and I'm experiencing some trouble.

After removing the bad drive from the array in mdadm, I replaced the drive with another 500GB spare drive which came with a new bought PC. The drive had a NTFS partition with Windows on it (had been immediately replaced with a SSD).

First try went (more or less) wrong - NTFS3G saw the partition and I was abled to add the NTFS volume to the array and it started to rebuild. Using NTFS underneath my RAID was definitely not my intention so I stopped the rebuild and started repartitioning the drive.

At first I tried partitioning manually with fdisk (max. size, default values, partition type "fd") - didn't work, mdadm rejected sda1. Quick check with fdisk - Start, Blocknumber and End didn't match - ok, I see the problem.

Second try was to copy the partitioning data from one of the other disks with "sfdisk -d /dev/sdd | sfdisk /dev/sda". I even zeroed the first 512Byte as sfdisk recommended at the end of his comments. Compared the partitioning data - Start, End and number of blocks matched - looks good.

But now mdadm tells me, that /dev/sda1 is no block device and won't let me add it. But it is possible to destroy the partitioning data on /dev/sda and to give mdadm the whole drive and it will rebuild, but this looks somehow wrong now:

 Number   Major   Minor   RaidDevice State
   4       8        0        0      active sync   /dev/sda
   1       8       17        1      active sync   /dev/sdb1
   2       8       33        2      active sync   /dev/sdc1
   3       8       49        3      active sync   /dev/sdd1

And I definitely don't feel completely well about it, when fdisk now finds no partitions on /dev/sda - In the case of a system crash it seems to be a little more tricky to reassemble the array on a different system when the whole drives are used instead of partitions (see also: here).

What did I miss? How can I tell mdadm to use the partition for its RAID? Or would anyone still recommend using the whole drives (and even converting the other ones)? Or does it really make more sense what the debian installer did there (set up partitions over the complete drives to create the RAID out of partitions)?

I hope I didn't give too much text and too many details, but I'm a little cofused now that I did everything like several tutorials recommended and now I'm stumbling upon these basic questions...

Thank you for your help!

2 Answers 2


First of all, I don't think there's anything wrong with using a complete drive for mdadm. In other words, your setup works now, you won't have any advantage from fiddling with it any further. From the answer you're referring to:

RAID-on-partition has its uses, but when you're using the drives in a pseudo-storage-pool setup, you're sometimes better off using 'whole drive' instead of 'partition' RAID members.

Now if you want to use partitions anyway: What you did the first time was correct, but it looks like the kernel didn't register /dev/sda1. Either the kernel didn't register (just reboot and it'll solve itself) or you used GPT-partitioning for the other drives (which sfdisk doesn't support AFAIK - you just copied the protective MBR). Try again with a tool like gdisk or gparted.

You could remove /dev/sda from the raid (marking as failed, removing it from the array), make a sensible partition layout (if you're using GPT, make sure you use gdisk or the likes), reboot if necessary and add /dev/sda1 to your RAID array.

  • First of all thank you for your answer! Sorry I forgot to mention some things: I use MBR on all drives (sfdisk copies that too as I understood so far) and I also partprobed the drive after all changes, so that my system should find the partitions. Jul 30, 2015 at 7:34
  • If you use MBR, then sfdisk should work fine. The only reason I can think of that sda doesn't exist, would be that something is using the disk. 500GB is not too big for MBR… You could try partitioning the disk in another machine.
    – jornane
    Jul 30, 2015 at 8:23

I like to fill used drives with zeroes before re-purposing for mdadm use. It makes the drive factory fresh and avoids these kinds of problems. This will fill /dev/sda with zeroes...

dd if=/dev/zero of=/dev/sda bs=1M
  • To avoid staring at a static screen for long minutes, you could use: part=xyz ; for disk in /dev/sd[$part] ; do echo ${disk} ; sudo dd if=/dev/zero | pv | sudo dd of=${disk}1 bs=1M iflag=fullblock ; done
    – boardrider
    Jul 16, 2019 at 22:49

You must log in to answer this question.

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