I have a 5-disk Intel RAID 5 along with a 6th boot disk with /, /boot, and swap.

What I was planning to do was mount the Intel RAID partitions (which I've added with fdisk) so that the 6th disk /home, /var, /srv, etc. link to the RAID on the other 5 disks. So far, my attempts at doing this have failed (editing fstab, trying to mount the /dev/dm-* partitions manually, etc.) have failed.

Does anyone have experience in this and can point me in the right direction?

Edit: I have the RAID array partitioned so that I can mount each partition as a folder on the boot disk, i.e. RAID /dev/dm-0 -> bootdisk /home.

migrated from serverfault.com Jul 19 '12 at 3:11

This question came from our site for system and network administrators.


You have a fake hardware raid controller. In reality it is a pure software raid, that happens to have bios support. If you do not need to dual boot with Windows, then you are better off not using it, and instead using pure Linux software raid, which has far better support. To rebuild the system that way, first delete the raid array in the bios utility, then reinstall Ubuntu using the alternate or server installer and configure software raid. You don't even need a separate disk or /boot partition: you can just use all 6 disks in one big raid. As Hennes mentioned, you may also want to use LVM on top of the raid array so you can subdivide it into smaller volumes that can easily be expanded in the future if needed.

You might want to read:




This seem trivial, which probably means I misunderstood it.

If I understand it correctly:

  • One disk with /, /boot and swap.
  • One disk on a RAID array with other directories, such as /var, /srv etc.

What prevents you from booting, mounting the disksand creating soft links from / to the folders on the RAID array? Or did you make separate partitions from /var etc. on the RAIDED drives?

If it is just one huge volume (e.g. mounted under /my_raid) then:

  • Boot (optionally single user mode, but with things mounted RW)
  • Copy files to the RAID (e.g. cp -r /srv /my_raid/ )
  • Remove the original (e.g. mv /srv /srv.old )
  • Make a softlink. (e.g. ln -s /my_raid/srv /srv )

If you try this with /var and /var is in use then you might need to boot in single user mode, or even from a liveCD.

If you made separate partitions on the RAID array then it gets a bit more complicated. In which case we need a bit more information in your post.

  • Sorry, I'm a bit of a novice at this. I have one disk with /, /boot, and swap. I have 5 disks as a single RAID5 array with /var,/srv, etc. I'm not exactly sure how to mount the Intel RAID onto disk. I've tried: sudo mount /dev/dm-1 /mnt/root/srv but that's given me an error saying there is no such mount point (I created folder /mnt/root). Also, I have the RAID array partitioned with each partition representing a folder on the boot disk (dm-0 -> /var, dm-1 ->/home, etc.). – BLaZuRE Jul 19 '12 at 0:19
  • Googling around on those it seems that you are using LVM logical "devices". That is something I never worked with. My experience with GNU/Linux was with plain old harddisks on SCSI cards, stable entries in /dev/ and simple filesystems on those. No LVM, no /dev/ that gets updated on labels etc. :( – Hennes Jul 19 '12 at 0:39
  • Question for moderators or people who used SF longer: Should I just delete my post since it does not contain the answer? – Hennes Jul 19 '12 at 0:42

Instead of symlinks, why not use LVM on your RAID array to divide it into multiple logical volumes, and just mount those volumes in the normal way?

Alternatively, you could just install your OS within the RAID array. No need to have it on a separate disk, where you risk losing it and having to reinstall the system if that disk dies. LVM lets you have as many logical volumes (essentially partitions) as you want, all on the RAID.


If I understand you correctly, you have one boot/OS disk and a RAID5 array which has been partitioned, and each of those partitions has been formatted. You want to mount partitions of the array as /home, /var, and others.

If so, then:

  1. Unless you're really attached to the Intel fakeraid then convert to linux software raid as suggested by psusi. mdadm really is much better than any of the fakeraid controllers (they're just software raid with BIOS and/or Windows driver support).

    Alternatively, install zfsonlinux (pre-packaged for ubuntu) and set up one big raid-z zpool. zfs gives you all the benefits of raid+lvm plus a whole lot more without the hassles.

  2. Reboot to single-user mode (you'll have data in existing /var, /home etc that needs to be moved to the array. it's best if that is done while noting else is using those files, and some of it MUST be done while nothing else is using them).

  3. For each of the partitions that you want to mount:

    3.1 format the partion if it's not already formatted.

    3.2 mount the partiton as XXXX.new where XXXX is the name of the subdirectory you want to move to the array. e.g. var.new, home.new - you will need to make the directory if it doesn't already exist.


    mkdir /var.new
    mount /dev/dm-1 /var.new

    3.3 rsync the original directory to the newly mounted directory, e.g. rsync -avx var var.new

    3.4 move the old directory out of the way, and move the new directory into place. e.g.

    mv var var.old ; mkdir /var

    If you want to see what the final state will be like before you reboot, then you can remount the partition. e.g.

    umount /var.new ; mount /dev/dm-1 /var ; rmdir var.new

    3.5 edit /etc/fstab and add the new mountpoint. e.g. if /home is /dev/dm-0 and /var is /dev/dm-1, and both are formatted as ext4 then you'll want to add lines like this to /etc/fstab:

    /dev/dm-0   /home  ext4  defaults     0       2
    /dev/dm-1   /var   ext4  defaults     0       2

    (you may want other mount options like relatime or nodiratime after "defaults")

  4. After all that's done you can reboot, and you can delete the *.old directories at your leisure. same for any (empty) *.new directories if you didn't delete them in step 3.4.

If you use zfs then the procedure will be slightly different. You won't need to format or mount the partitions (just zfs create poolname/XXXX.new for each fs you need), and you wont have to edit /etc/fstab (just change the mountpoint property for each fs, e.g. zfs set mountpoint=/var poolname/var.new)

BTW, in case you don't know: some directories MUST be on the root filesystem. /bin, /sbin, and /etc. most modern linux distros don't cope well with /usr being on a separate fs either.


I boot from a software RAID partition, in a manner similar to yours. One thing I learnt the hard way was that /var needed to be on the same logical partition as /, and /usr/lib probably did, too.

My RAID is configured in the BIOS with Intel Matrix Storage Manager. The RAID device has two partitions; one NTFS and one ext4, for dual-booting into Windows and Linux. I try to access the Windows partition as little as possible when running Linux, and vice-versa. The only problem I've ever had with it was a BSOD in windows with an error message about ntfs.sys. Long story short, I had to rebuild one of the my hard drives and reinstall Windows...

Installing Ubuntu onto the partition initially was a bit of a problem, as I didn't have an Ubuntu installation CD which could recognise the RAID device without first installing extra software (dmraid). So I booted into a Live CD, installed dmraid,and then installed Ubuntu on to the RAID using the debootstrap / chroot method. It's been fine ever since (over 2 years now). I don't have LVM or mdm installed.

In hindsight, if I were to rebuild my system from scratch, with your number of hard drives and no need for Windows, I'd almost definitely use ZFS instead of Intel's RAID manager.

Rebuilding software RAID arrays is done in the OS, so in my case I had to get familiar with using dmraid on the command-line. It was a bit scary, to be frank.

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.