# How do md  devices get assigned for initramfs load? [SOLVED]

## John Klug

How does the system know during boot which /dev/sd? devices correspond to which md devices.

I have an md system that works, and am trying to make a 2nd one, but the 2nd one fails to load the devices.

Looking at my working system's initramfs file, /etc/mdadm.conf is not present.  I would think it would be too late if it were in there anyway.

So how is the mapping done during boot assuming one uses genkernel?  I used grub manually to specify root as follows:

root (hd0,0)

setup (hd0,0)

root (hd1,0)

setup (hd1,0)

Boot and initramfs are in the first disk and second disk in the first partition,  which is ext2.  Since the root menu works, It must be getting to the boot parition.

My non working system sees:

```
NET: Registered protocol family 17

registered taskstats version 1

Freeing unused kernel memory: 388k freed

```

Then gets: 

```
request_module: runaway

loop modprobe binfm-0000

loop modprobe binfm-0000

loop modprobe binfm-0000

loop modprobe binfm-0000

loop modprobe binfm-0000
```

I duplicated the disks, but moved swap out of /dev/md, so the first md partition is boot, the 2nd is root, and the 3rd md partition is home, but on the disks themselves, the 3rd partition is swap, and the 4th partition is home.

real_root is set to /dev/md2.  Boot was /dev/md1 when I ran grub and genkernel and is in /etc/mdadm.conf.Last edited by John Klug on Fri Dec 18, 2009 7:29 am; edited 1 time in total

----------

## cassiol

helooo

this wiki help you with raid http://en.gentoo-wiki.com/wiki/RAID/Software

if you have more question, please post again 

good luck

----------

## John Klug

It looks like genkernel does not save /etc/mdadmin.conf.  I suppose it could be added with an overlay to genkernel, but the above md line would be eaiser.

This answers my question, but I will open a new topic, since I now am closer to understanding my immediate problem (request_module: runaway ...), which lies with genkernel.

----------

## drescherjm

It normally does save /etc/mdadm.conf if you enable this in /etc/genkernel.conf

----------

## John Klug

So after putting in the /etc/mdadm.conf file in the initramfs file, it doesn't seem to do the assemble.

The boot complains about not finding real_root, and then I have to go into the shell and do:

mdadm --assemble

Then it creates my md devices.

Then I can continue the boot.

So how can I get mdadm to run automatically?

Is there any way to use the UUID number in /etc/mdadm.conf into the kernel line in grub.conf/menu.lst something like:

real_root=UUID=f7c6a4ab:69c4a123:120cd85d:8196c2c5

In my genkernel.conf I already have:

```
MDADM="yes"

DISKLABEL="yes"
```

----------

## drescherjm

I use these options on several machines here at work. All of my servers boot off of mdadm raid. I am not sure how many of them use the uuid syntax however. I know I do that at home. Do you have all the required drivers compiled into the kernel or are they modules? I have had issues when some parts were modules so I compile in raid456 and ext4/reiserfs.

----------

## drescherjm

Here is one:

```
datastore3 ~ # cat /boot/grub/grub.conf

default 0

timeout 30

splashimage=(hd0,0)/grub/splash.xpm.gz

title=Gentoo Linux (2.6.27-openvz-briullov.1-r4-openvz-ext4-new)

root (hd0,0)

#kernel /kernel-genkernel-x86_64-2.6.27.21-openvz-ext4-new-00011-g36d3faf-dirty root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=UUID=02b51f64-ceed-4570-943f-7f0295b26a61 dolvm md-mod.start_dirty_degraded=1

kernel /kernel-genkernel-x86_64-2.6.27-openvz-briullov.1-r4-openvz-ext4-new root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/md1 dolvm md-mod.start_dirty_degraded=1

initrd /initramfs-genkernel-x86_64-2.6.27-openvz-briullov.1-r4-openvz-ext4-new

```

Hmm looks like I disabled the uuid syntax on this one...

----------

## John Klug

I think the kernel doesn't seem to know about UUID for md.

Anyway, another one of my problems was that the disks came from another system (where I loaded them with gentoo), and one of the partitions got the wrong md number when the kernel booted, that did not match /etc/mtdamd.conf, because it was a rather high number.  I tried to change /etc/fstab and /etc/mdadm.conf to match the kernel's version of the super-minor number, but then it wouldn't mount because mount said the partition was bad after the disk was assembled.

So I had to zero out the partition and re-create the md device number so that things wound up consistent.  Apparently only --create can set the super-minor number. 

So the super-minor numbers are essentially labels on the disks, so maybe you don't need the UUIDS.  You just have to keep zeroing the superblocks to avoid minor number conflicts.

----------

## richard.scott

Hi,

do you still get this output when booting:

```
request_module: runaway

loop modprobe binfm-0000

loop modprobe binfm-0000

loop modprobe binfm-0000

loop modprobe binfm-0000

loop modprobe binfm-0000
```

and then it all stops?

if so, see this thread:

https://forums.gentoo.org/viewtopic-t-807219-highlight-genkernel+zero.html

I had to upgrade cpio to the next version to fix my systems.

Rich

----------

## John Klug

I wrote topic 807219.   I didn't need to update cpio to fix my problem.  Maybe I was just lucky?

----------

