Slackware 12, changing to generic kernel on raid1, mkinitrd issue
 

I'm trying to set up a workstation to have /boot on raid1 (/dev/md1) and / on raid0 (/dev/md0).. to do this I've first installed using the huge.smp kernel, created a raid-viable lilo, rebooted (works fine), then linked System.map, config and vmlinuz in /boot to their generic-smp versions. This won't work for 2 reasons: the root filesystem is reiserfs, and support for that is not compiled into generic-smp. So I need an initrd. That brings me to the second problem: initrd doesn't have raid support built in.

To fix this I mainly followed this article:

http://apropos.wordpress.com/2007/07...-raid-und-lvm/

So what I did was edit /usr/share/mkinitrd/initrd-tree.tar.gz to include /sbin/mdadm and /etc/mdadm.conf (this has the output from mdadm -D --scan appended), and add /sbin/mdadm -A --scan to the included init script, to assemble the raids before mounting the root filesystem.

I created my initrd using mkinitrd -c -k 2.6.21.5-smp -m reiserfs -r /dev/md0 -f reiserfs and checked the resulting /boot/initrd-tree to make sure it contained sbin/mdadm and etc/mdadm.conf and the modified init script.. which it did. I added initrd = /boot/initrd.gz to my lilo config, ran it, and rebooted.

Kernel panic.

It shows it has loaded the reiserfs module, but mdadm has failed to create /dev/md0 and /dev/md1, so mounting the root obviously fails.

I'm stumped, because I've used the exact same procedure on a similar machine and it worked fine.

Can anyone offer any insight as to why it can't assemble the arrays? It has the required program, /sbin/mdadm, and it has the information needed, /etc/mdadm.conf. I've also tried to assemble the arrays explicitly using mdadm -assemble /dev/md0 /dev/sda3 /dev/sdb3 in init, instead of mdadm -A --scan, but I got the same result.

When you use Software RAID and have RAID built into the kernel, like with the huge(smp) and generic(smp) kernels, and you set your partition types to "fd" (Linux RAID autodetect) then you should have no need for mdadm in the initrd because the kernel will take care of everything.

Eric

Thanks for your reply. If only it were that simple. :) I double checked in cfdisk at install time to make sure all the partitions were set as FD (they were), and while raid support is built into both flavors of the kernel, simply making an initrd with just reiserfs in it is not enough.

In the meantime, I've also tried with the latest mkinitrd package from -current, both with and without added mdadm, and got the same results. All that changed was that I now get a prompt after it panics, but it doesn't accept input. :D

Hi there. I had similar issues with a new Slack 12 box at work recently. My box worked fine with the same type of solution that you had, although my etc/mdadm.conf was more generic:

$ cat etc/mdadm.conf
DEVICE /dev/sd*
ARRAY /dev/md0 super-minor=0
ARRAY /dev/md1 super-minor=1

I then added "/sbin/mdadm --assemble --scan" to the "init" file.

If these changes don't help, the next thing I would suggest is to simply add a "sh" line to "init", so you get a usable shell. Then try using mdadm from there and debug it interactively. :)

Hi,

With the current's initrd you got the "Kernel Panic" and *after* the panic a shell prompt? This is very strange. Can you try:

LILO: your-kernel-image rescue

This will start the initrd with a rescue shell. A better place to debug something, and saw if the /dev/mdX devices are in place, if you can mount it, etc.

Probably, like most of ppl (including me), you don't have a serial or lanconsole enabled. If you can hand copy (or take a good picture -;)) of the error, i will be happy.

Thanks!

Piter PUNK

I ran through the whole sequence again just to be sure, and to get the exact error messages. First, I used the original, unmodified mkinitrd package in Slackware 12.0 to create an initrd with reiserfs as follows:

/lib/modules/2.6.21.5-smp exists, /dev/md0 is my root partition, made up of /dev/sda3 and /dev/sdb3 in a raid0 configuration that I created with mdadm during install.

I symlinked System.map, config and vmlinuz to their respective "generic-smp" versions, edited and updated lilo, then rebooted. This is what I got:

Unless there is some flaw in my method, this at least proves that it does not in fact work "out of the box", following the README.initrd and using the supplied mkinitrd package.

Then, I put the install disk back in, booted into my system with the hugesmp.s kernel, and upgradepkg'd the mkinitrd package using the latest version in -current, 1.2.0-i486-1. I created a new initrd, updated lilo, rebooted again and got this:

I can't type at this prompt, and I can't ctrl+alt+del or anything, it just hangs here. It does *not* explicitly say "Kernel panic", apologies for misleading you by saying so earlier. Still, the total lack of response makes me suspect something is quietly panicking in the background.. :D

I rebooted once more, using LILO: Linux rescue to get initrd into rescue mode, and I ended up with a similar "you can fix it" type message, the same /bin/sh message and the same unworkable prompt.

I also tried TransAMrit's suggestion; unfortunately it gave me the same result as with my own mdadm.conf. :(

Thanks for the feedback so far, I'll be more than happy to supply more information / do more testing to help solve this!

Did you also try the "sh" suggestion? At the same point where you added the call to mdadm in init, add a call to sh, so you can get into a shell and do things like poke around /dev and see if all your nodes exist, run mdadm with various options to try and provoke some useful error message, etc.

I have, and I got an unusable prompt again.. I am using a USB KVM so just in case, I tried with a keyboard plugged in to the machine directly as well, no luck.

I sent Pat a patch for this very issue but never heard anything back, this works for me but YMMV.

This adds a -M option for mdadm raid support.

I also forgot to tell you to add this to the init script
edit _initrd-tree.tar.gz and add this to the init script and recreate the tarball

Hi, thank you for your reply. I'm at work so I can't try now but I will do so tonight.. reading through your patch it is mostly the same as what I've been doing all along, except for two differences.

First, you put your mdadm.conf in $SOURCE_TREE/etc/mdadm/mdadm.conf where mine was simply in $SOURCE_TREE/etc/mdadm.conf, same as on the live system.. but that shouldn't make much difference; man mdadm tells me it tries both.

A more interesting difference is that you use mdadm -E where I used mdadm -D.. the man page tells me -D gives details of an MD device, and -E looks at the MD superblock on a device.. that doesn't tell me much. :D I ran both with -s and got identical output. How does -E differ from -D?

Tried it.. my mileage does vary, it still won't assemble the raid. :(

However, I managed to get a usable shell for debugging now. I tried mdadm -D -s and it gave me nothing. mdadm -E -s gave me the correct information, which is also in /etc/mdadm.conf.

I then tried mdadm -A -s, didn't work.. "failed to create /dev/md0".

I checked /proc/partitions, it lists my sda/sdb correctly, so then I checked the /dev tree. This is where it becomes interesting. It has nodes for /dev/md0 and /dev/md1 but they are links to /dev/md/0 and /dev/md/1, respectively, and neither of those exists.

I fiddled around with the --auto=[yes,md] options which supposedly create device nodes when needed, but the man page is cryptic at best here and I may well have gotten it wrong.

I don't really know where to go from here, what should I try next?

That is odd that it can read the info from the superblock but cant assemble the raid. Just to make sure you are rerunning lilo after you edit the initrd?

I also forgot to tell you to add this to the init script
edit _initrd-tree.tar.gz and add this to the init script and recreate the tarball

Yes, I am. :)

I kinda figured as much and added that in myself. I also added a call to /bin/sh after the call to mdadm, as per TransAMrit's suggestion.. had to get a PS/2 keyboard to be able to use the shell (doh!) but at least I can do some debugging now.. or I could if I knew where to look next. :)

Have you had any luck with this issue? Or are you still stuck?

Hi, I have seen this forum only now :-(
Somebody knows why this patch isn't merged in official Slack?

Today I had the same problem,
understood that kernel raid autodetect don't run if there is an initrd...
and finally, after several test, I wrote a patch very similar to your one,
the only differences:

generate mdadm.conf at boot time;
fixed a cp (if run mkinitrd without options it copied missed devices in dev/dev);
copy symlinks AND relative devices, so I have /dev/md1 and /dev/md/1:
mdadm automatically create only /dev/mdx,
but my root is autodetected as /dev/md/1 (from mount)
and so I don't need to use -r

My patch: