initrd issue, building new kernel

jcas1411 · 12-02-2010, 04:47 PM

Okay, Let explain what I'm doing so maybe someone can help.

Started with slackware 13.1, minimal install, no kde, etc, did not update to current. I compiled kde3.5.10 from source adding in all the required libraries. I downloaded 2.6.35.8 from kernel.org patched for squashfs and aufs (building live cd) and used config from the huge kernel on the cd, made my initrd etc. boots works great (booting with lilo). wanted to slim down kernel (modules rather than built in drivers) and build for multi architecture enviroment so recompiled kernel again with new config file. compiles fine, maked my new init.. now when I reboot I dont see it loading my scsi drivers lcisas scisi generic. I'm getting a kernel panic after md scan.

Cannot open root device "801" or unknown block (8,1)
please append a correct root = boot option here are the available partitions
sr0 driver sr
kernel panic not syncing VFS: unable to mount rootfs on unknown block (8,1)

My saving grace is that I have a backup and can try again, however no luck on getting it to work. Same issue each time.

John

andrewthomas · 12-02-2010, 04:53 PM

You really should build-in support for your file systems and for your hard drives into your kernel. Most of the rest can be modules.

Richard Cranium · 12-02-2010, 06:03 PM

So, what filesystem type is "/"? What mkinitrd command did you use to generate your initrd? What is the contents of /boot/initrd-tree/load_kernel_modules?

You don't have to compile in your root directory's filesystem into the kernel. I haven't done that for years.

FWIW, my /boot/initrd-tree/load_kernel_modules contains...

Code:

# This is a script used to load the kernel modules.
# To use it, chmod it 755, and then add the insmod
# lines needed to load your modules, like this:

insmod -v /lib/modules/$(uname -r)/kernel/fs/mbcache.ko
insmod -v /lib/modules/$(uname -r)/kernel/fs/ext2/ext2.ko
insmod -v /lib/modules/$(uname -r)/kernel/fs/jbd/jbd.ko
insmod -v /lib/modules/$(uname -r)/kernel/fs/exportfs/exportfs.ko
insmod -v /lib/modules/$(uname -r)/kernel/fs/xfs/xfs.ko
insmod -v /lib/modules/$(uname -r)/kernel/drivers/scsi/aic7xxx/aic7xxx.ko

...and it was generated by the oddly little-known script /usr/share/mkinitrd/mkinitrd_command_generator.sh.

jcas1411 · 12-03-2010, 02:50 PM

mkinitrd -c -k 2.6.35.8 -f ext2 -r /dev/sda1 was what I was running so

I used the shell sript you mentioned and it told me to use this mkinitrd command

mkinitrd -c -k 2.6.35.8 -f ext2 -r /dev/sda1 -m usbhid:ehci-hcd:uhci-hcd:ext2 -o /boot/initrd.gz

which resulted in this.

Code:

# This is a script used to load the kernel modules.
# To use it, chmod it 755, and then add the insmod
# lines needed to load your modules, like this:

insmod -v /lib/modules/$(uname -r)/kernel/drivers/hid/usbhid/usbhid.ko

One line, and I can see it is not loading the lsi sas module nor the ext2. I verified I did build ext2 into the kernel rather than as a module.

Can I edit this manually now and get it to load the sas driver? do I have to run lilo again, kernel boots to a panic state so will have to do via boot disk and running lilo from that is a nightmare.

Thanks for any help,
John

wildwizard · 12-03-2010, 04:06 PM

Question for the ages :- Why do people always do things the hard way?

Revert your system back to the working kernel
Create an extra lilo entry for the working kernel configuration by copying the kernel image to a new name that makes it obvious that it is there for emergencies (try /boot/known-good-kernel)

You mention in the last post that you have a LSI SAS controller but you don't seem to know which driver it uses?

If we can't determine the driver now then lets include all the drivers until we do (These are the only ones I can see)
mkinitrd -c -k 2.6.35.8 -m megaraid_sas:mpt2sas

If you have your filesystem as a module then include it as well

You should now have a working new kernel w/initrd and a backup kernel if the new one doesn't

jcas1411 · 12-03-2010, 04:24 PM

yeah, understand I went about this a bit the hard way, restoring prebuild as we speak.

I do know what driver I need loaded,after inspecting with previous build's lshw
LSI Logic/Symbios Logic SAS1068 PCI-X Fusion MPT SAS
driver module it loaded on previous build is mptsas.

The biggest issue I guess is I dont understand initrd very well or at least as much as I would like.

After I get my kernel booting again I also would like to fix another issue. I tried to mount my initrd to remove junk I dont need, and when I typed
cp /boot/initrd.gz /root
gunzip /root/initrd.gz
mount -o loop /root/initrd /mnt/cdrom

it stated I needed to specify filesystem type. this is how the docs show to mount it as a loop device. any suggestions?

Thanks for your help!
John

bgeddy · 12-03-2010, 05:21 PM

Quote:

After I get my kernel booting again I also would like to fix another issue. I tried to mount my initrd to remove junk I dont need, and when I typed

Although I'm no expert with mkinitrd I'm pretty sure you don't have to bother with the mounting issue. If you really need to hand edit the initrd components just work on /boot/inird-tree. I'm pretty sure mkinitrd will use the options in /boot/initrd-tree unless you supply the -c option when a new initrd-tree will be built. In other words without the -c option I think it uses what it finds it /boot/initrd-tree to generate the initrd. Be aware that there is a very useful script at /usr/share/mkinitrd/mkinitrd_command_generator.sh which will give the command to get mkinitrd to generate the required initd command.

Edit: Apologies - I see the mkinktrd_command_generator.sh script has already been mentioned by Richard_Cranium. Sorry Richard.

wildwizard · 12-03-2010, 08:33 PM

As bgeddy says don't mount the created image to remove stuff but rather recreate it using mkinitrd with only the modules you need.