SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
mkinitrd -c -k 2.6.27-rc6 -m ext3
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.
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.
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.
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?
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%.
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:
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
option 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:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.