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