[arch-general] Why Is My RAID Installing Failing?

[Baho Utot]

On Tuesday 12 January 2010 07:56:15 pm Alexander Duscheleit wrote:
> On Tue, 12 Jan 2010 11:19:04 -0500
>
> Carlos Williams <carloswill at gmail.com> wrote:
> > Thanks for everyone's input. It appeared to have failed both ways. I
> > guess Arch is not in the cards for me. It sucks because I love the
> > rolling release aspect of Arch. I just find the documentation very
> > confusing and something as simple as RAID should be far more
> > simplistic even for a text based installer. Hopefully developers are
> > looking into improving this in future releases.
>
> I didn't know, where to put a proper reply in this thread, because
> basically you are all doing the same mistake. I will just outline the
> procedure here briefly and then explain where it all went wrong :)
>
> 1 - cfdisk  # the settings in Carlos' 1st mail look sane
> 2 - modprobe raid1
> 3 - mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2
> 4 - /arch/setup # we save the mdadm -D --scan for later
> !!!! 5 - before getting to the "Configure System" part,
>          open up another console (Alt-F2) and do
>          mdadm -D --scan >> /mnt/etc/mdadm.conf
>          (you have to do this before mkinitcpio runs
>          in the "Configure" stage, but after the target
>          system is mounted, so between "Install Packages"
>          and "Configure System" should be fine)
> 6 - continue the setup as described in OP (skip the cp -a part)
>
>
> Now to why you have to do it this way:
> the file /etc/mdadm.conf tells mdadm where the proper disks/partitions are
> to find to build it's arrays. Therefore the mdadm hook adds this file
> to the initrd together with the mdadm binary. The mdadm call during init
> will then use this file, assemble your arrays and then hand of the boot
> process to the "real" system.
>
> All your tries with the "new methos" thus just failed, because you copied
> /etc/mdadm.conf too late, and it was never added to the initrd file. Mdadm
> inside the ramfs just never knew what to look for.
>

Only if you use the madam hook,  I use just the raid and encryption hook and 
it works for me.

I am using raid5 with encrypted root and home filesystems (on the Arch 
install) , everything is encrypted except /boot ( it is not mounted  into the 
filesystem and is not in fstab )

> You also have to remember later, to regenerate mdadm.conf and your initrd
> everytime you change major parts of your RAID setup.
>
> I hope this helps to clear some things up.
>
> Greetings,
> 	jinks
> (running mdraid with the "new method" on at least five boxes atm :))

Ok, I am wrong.

That's why my system boots and runs without a /etc/mdadm.conf

Let me suggest you have a look at the raid howto on slackware12.2 or 13.0 dvd.

ftp://carroll.cac.psu.edu/pub/linux/distributions/slackware/slackware-13.0/README_RAID.TXT

Slack uses lilo but if you define the array on the kernel line in grub it 
works just the same.

/boot/grub/menu.lst

timeout 5
default 41
color green/black light-green/blue

title ArchLinux x86_64
root (hd0,1)
kernel /vmlinuz26 cryptdevice=/dev/md2:root root=/dev/mapper/root 
md=2,/dev/sda5,/dev/sdb5,/dev/sdc5 ro
initrd /kernel26.img

title Slackware 12.2-x86
root (hd0,1)
kernel /Slackware/vmlinuz root=/dev/md2 md2=,/dev/sda5,/dev/sdb5,/dev/sdc5

Notice no initrd in the above

Here is /etc/mdadm.conf from Slack and the Arch install has an empty file 
for /etc/mdadm.conf.

Please read the second paragraph, closely read the functioning of madm without 
a configuration file.

# mdadm configuration file
#
# mdadm will function properly without the use of a configuration file,
# but this file is useful for keeping track of arrays and member disks.
# In general, a mdadm.conf file is created, and updated, after arrays
# are created. This is the opposite behavior of /etc/raidtab which is
# created prior to array construction.
#
#
# the config file takes two types of lines:
#
#	DEVICE lines specify a list of devices of where to look for
#	  potential member disks
#
#	ARRAY lines specify information about how to identify arrays so
#	  so that they can be activated
#
# You can have more than one device line and use wild cards. The first 
# example includes SCSI the first partition of SCSI disks /dev/sdb,
# /dev/sdc, /dev/sdd, /dev/sdj, /dev/sdk, and /dev/sdl. The second 
# line looks for array slices on IDE disks.
#
#DEVICE /dev/sd[bcdjkl]1
#DEVICE /dev/hda1 /dev/hdb1
#
# If you mount devfs on /dev, then a suitable way to list all devices is:
#DEVICE /dev/discs/*/*
#
#
#
# ARRAY lines specify an array to assemble and a method of identification.
# Arrays can currently be identified by using a UUID, superblock minor number,
# or a listing of devices.
#
#	super-minor is usually the minor number of the metadevice
#	UUID is the Universally Unique Identifier for the array
# Each can be obtained using
#
# 	mdadm -D <md>
#
#ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
#ARRAY /dev/md1 super-minor=1
#ARRAY /dev/md2 devices=/dev/hda1,/dev/hdb1
#
# ARRAY lines can also specify a "spare-group" for each array.  
mdadm --monitor
# will then move a spare between arrays in a spare-group if one array has a 
failed
# drive but no spare
#ARRAY /dev/md4 uuid=b23f3c6d:aec43a9f:fd65db85:369432df spare-group=group1
#ARRAY /dev/md5 uuid=19464854:03f71b1b:e0df2edd:246cc977 spare-group=group1
#
# When used in --follow (aka --monitor) mode, mdadm needs a
# mail address and/or a program.  This can be given with "mailaddr"
# and "program" lines to that monitoring can be started using
#    mdadm --follow --scan & echo $! > /var/run/mdadm
# If the lines are not found, mdadm will exit quietly
#MAILADDR root at mydomain.tld
#PROGRAM /usr/sbin/handle-mdadm-events