Small patch for activating mirrored configurations

Erik Agsjö erik.agsjo at noptec.com
Mon Oct 4 21:01:49 UTC 2004


Well, this is somewhat of a hack  that seems to work for me so far.
Sorry if this is a bit long, but it might be interesting to know how I
got here.

When I bought by motherboard (Asus A7N8X-E) I thought it was nice that
it has SATA with RAID, but I just bought one hard drive to get up and
running, thinking I would get some time to look into the RAID situation
later.

So I started out by installing Debian stable using the Silicon Image ATA
drivers, accessing my drive as /dev/hda. I created two partitions, root
and swap and saved some space for later. I wasn't sure if I was going to
be dual booting. When I later upgraded my kernel to 2.6.8  I realized
that I might be better off using the SCSI SATA drivers, so I switched,
now accessing my drive as /dev/sda.

Then I went and bought another drive and set it up in BIOS to mirror the
first drive. Note that at this point I didn't know that I only had BIOS
supported software RAID. (I really thought it was hardware :) When I
booted up after the BIOS was done creating the initial copy, I started
looking for some kind of software or driver that would help me check the
status of my newly created mirror. That was when I learned about the
whole situation and found "dmraid".

I was glad I hadn't partitioned the whole drive, leaving the meta data
blocks untouched!

I didn't realize that device-mapper creates it's own device nodes, and I
didn't want devfs, so I installed and configured udev. I then played
with "dmraid" to get the mappings for the whole device and the
partitions. After some basic checks I found that "dmraid" had identified
my mirrored configuration correctly, but I could obviously not activate
it since I had file systems mounted on the mother device.

This is where I started to play with initrd.

My initrd is stripped down, not generic enough for everyone, but might
be a starting point for others. It uses busybox for most binaries (for
simplifying dependencies really), but "dmraid" is dynamically linked,
and so is "udevstart" and "udev".

My linuxrc is almost like the one from "mkinitrd", it hardwires the root
device to /dev/ram0 and then lets the kernel load init, so that init
arguments are handled correctly (if there's another way of doing this,
let me know). My /sbin/init then does most of the work by getting the
root device name from the kernel command line, initializing udev,
running "dmraid -ay", mounting the root device, running pivot_root and
finally passing control to the real init.

Since I couldn't get the partition devices activated while I had
/dev/hda busy, I appended a custom kernel argument
"raidroot=/dev/mapper/sil_0409172255062_p1" to my LILO entry. I had
found out that much by running "dmraid -ay -t" earlier. I guess this is
how I tell dmraid from lvm or evms; I don't.

There is still much work to be done here. I basically don't verify
anything. One interesting detail now is that my installed lilo version
doesn't handle device-mapper, so I cannot run lilo anymore. There must
be a  patch somewhere for that, right?

Hope this helps. I can post my linuxrc/init if you like.

/Erik

On Mon, 2004-10-04 at 19:07, Luca Berra wrote:
> On Mon, Oct 04, 2004 at 04:32:46PM +0200, Heinz Mauelshagen wrote:
> >
> >Erik,
> >
> >thanks for the patch.
> >
> >Managing to boot off a (mirrored) setup with dmraid/initrd is
> >interesting for a lot of people on this list.
> >Can you provide details on it for everyone, please ?
> 
> yes, especially how do you tell dmraid from lvm or evms?




More information about the Ataraid-list mailing list