Comment 36 for bug 990913

fwiw i found a workaround. first i thought it might involve containers but i couldn't get those working at all. so i cheated.

eg: (compressed process, took place more incrementally)

mdadm --create /dev/md/vol0 --level=0 --raid-devices=2 /dev/sda /dev/sdb
mdadm --create /dev/md/vol1 --level=0 --raid-devices=2 /dev/sdc /dev/sdd
mdadm --create /dev/md/vol2 --level=linear --raid-devices=2 /dev/sde /dev/sdf

(thus three 3T arrays created; already have 3 3T single drives too):

mdadm --create /dev/md/Vault --level=5 --raid-devices=6 /dev/sdg /dev/sdh /dev/sdi /dev/md/vol0 /dev/md/vol1 /dev/md/vol2

(and put a filesystem on it):

mkfs.ext4 -L Vault (other-options) /dev/md/Vault

(I think you got that far already. This is the workaround):

echo "AUTO -all" >> /etc/mdadm/mdadm.conf

(don't automatically assemble any arrays, just those listed in mdadm.conf. Specifically):

mdadm --detail --scan | grep vol >> /etc/mdadm/mdadm.conf

(So, we only assemble the sub-arrays automatically during normal mdadm startup)

Then into /etc/rc.local:

mdadm --assemble --config=partitions --scan

(*now* auto-enable any other arrays you can. /dev/md/Vault gets assembled then.)

sleep 10

(probably excessive delay to make sure it's assembled

mount -L Vault -o rw,nosuid,nodev,relatime,uhelper=udisks2 /media/Vault

so yeah, you can't have Vault mounted in fstab because the array isn't created in mdadm startup; so this *is* a workaround but it *does* work.