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: Quote:
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:
Code:
mkinitrd -c -k 2.6.27-rc6 -m ext3 -s /boot/generic-initrd -o 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 :)) |
Quote:
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
Code:
cd /path/to/kernel/directory |
Quote:
Quote:
|
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: Code:
strings <module name>.ko | grep vermagic |
Quote:
Code:
# mkinitrd -c -k 2.6.27-rc6-smp -m ext3 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 with Code:
-o /boot/2.6.24.4-noide-initrd.gz 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: Code:
mkinitrd -k 2.6.26.5-smp -f jfs -r /dev/cryptvg/root -C /dev/md/2 -L -R -o /boot/initrd.gz |
All times are GMT -5. The time now is 06:48 PM. |