mkinitrd Problem when trying to boot new kernel
 

Hello Everyone,

I was finally able to get kernel 2.6.27-rc6 installed and compiled, and it starts to boot successfully, then drops to a command line with the message that no kernel modules are present. I know this is a problem with the initrd.gz that I had made with this:

It would not load the needed modules with this initrd, and it overwrote the existing initrd I used to boot my generic kernel, so it wouldn't boot either until I remade it.

My question is, how can I successfully build a separate initrd.gz for the new kernel and keep from overwriting my existing initrd? I want to try this kernel because it has native support for my rtl8187B wireless chipset so I can stop using ndiswrapper.

Anyone have any ideas? Thanks for any replies.

Bob

It seems easy, just rename your initrd.gz, say BobNutfield.gz and add it in lilo.conf
unless I missed something ?

I thought of that. But for some reason, when I rename the current initrd.gz to say, generic-initrd.gz to boot my current generic kernel, and then run the mkinitrd script for the new kernel creating simply initrd.gz, it still boots only to the same command line. Maybe something wrong with the way I am building the kernel initrd?

I use Grub, by the way, which isn't an issue because I just edit the menu.lst file.

Thank you for the reply.

Bob

I don't think you can just rename initrd.gz because /boot/initrd-tree would still reflect the old initrd. Instead of using the '-c' option, which clears the existing initrd tree, you could leave that option out and just add the modules from the new kernel to the initrd. You could also play around with the '-o' and '-s' options if you want to avoid overwriting the existing initrd.gz and initrd-tree and create a whole new initrd.

You can use another directory than the default to make initrd like:
This will use /boot/generic-initrd as initrd source tree and makes initrd with the name: generic-initrd.gz
So this way you are sure that there will be no conflict

OK, I was successful in getting my current 2.6.24.5 kernel to boot fine renaming the initrd.gz to generic-initrd.gz. I then re-ran the mkinitrd for 2.6.27-rc6 kernel to create initrd.gz. Edited menu.lst and I get the same results when trying to boot the new kernel. I get a number of messages telling this module isn't present or that module isn't present, so I am beginning to think it is how I built the kernel configuration. I copied my old menuconfig so I would have a starting point.

I believe T3slider is correct about the initrd's I am building continuing to use the initrd tree in existence. Guess I just have to play a lot more to figure out what it is. This is the first time in loooong time I have tried to compile a new kernel, so I guess I have forgotten a lot. I followed Alien Bob's guide and everything went smoothly and I thought I was home free when the new kernel starting booting correctly.

Going to try to remake the initrd with T3slider's suggestion of omitting the -c option to see if I can build a completely separate initrd.

Did you remember to run `make modules` and `make modules_install` (that last one as root)? Is there anything in /lib/modules/2.6.27-rc6?

Why not include the ext3 support in kernel as built-in if you compile it ?
(this way no more initrd headache :))

T3slider: yes, those steps were completed and there is a collection of modules in /lib/modules/2.6.27-rc6-smp (I wonder if the name difference has anything to do with it since the kernel named vmlinuz-2.6.27rc6 does attempt to boot, or if it has anything to do with the mkinitrd?)

keefaz: I believe I DID include ext3 support in the kernel. It's long process, so I don't really remember 100%.

Check ext3 in .config
Now if you have ext3 built-in, you don't need the initrd line in menu.lst

Oops! Guess I did configure it as a module. Darn! I hate to spend all the time recompiling just to add that. There are still a number of things in the kernel config that I don't totally understand, but I just missed this one.

After trying the mkinitrd again without the -c option, it appears to still be using the initrd-tree that was in existence. Does anyone know how I can check which kernel a particular initrd is for? There does seem to be any indication in the initrd-tree directory.

Take your time in kernel config, it is worth it :)
Just remember to remove or comment the initrd line in menu.lst for the kernel you add ext3 support as built in
If you did not issue a make mrproper, I think the kernel compilation will be faster

[edit]
for checking which kernel version your initrd tree belongs to,
try find a .ko module in the initrd directory and use:

That would be the problem there. Your correct mkinitrd command should be
(change any mkinitrd options in that line -- for example, remove the -c option and possibly add the -s and -o options).

mkinitrd should take the directory under /lib/modules, NOT just the kernel version.

And in 2.6 kernels you run "make" and "make modules_install" --
no need for "make modules" -- make does that job now.

I think there is something amiss in the present mkinitrd script.
I say this because prior to Slackware-12.1, I could build a new
initrd withoption to have a separate initrd. But now those won't boot anymore.

I have not had the extra time to investigate. Now I just leave off
the -c option and use initrd.gz and add the modules to the existing
initrd and my kernels boot.

NB: I am using RAID, LUKS, and LVM -- much more complicated than
what you seem to be describing. So this is my mkinitrd command: