On Tuesday 12 January 2010 07:56:15 pm Alexander Duscheleit wrote:
On Tue, 12 Jan 2010 11:19:04 -0500
Carlos Williams <carloswill@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@mydomain.tld #PROGRAM /usr/sbin/handle-mdadm-events