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.
Is there any way to inspect the initrd file to find out the modules that it can use
(making compiling your own kernel easier because of the modules already identified in a suitable initrd)
Or are there better ways to determine all the modules (in the kernel / loaded or potentially loaded ) that your systems is using / can use for building your own kernel ?
You only need to have initrd load the file system modules that are need to read /boot. Once the the generic kernel loads, (mostly) everything required will get autodetected. This results in a much lower memory footprint and gives you a much faster system. The system will be much more stable and secure since there won't be unused modules loaded into memory.
Sure, on a 4GHz quad core with 16GB RAM, you may not notice it much. Some of us poor slobs with antique single/dual cores and <1GB RAM care about it.
2 members found this post helpful.
Click here to see the post LQ members have rated as the most helpful post in this thread.
You can try multiple kernels, but the generic/huge kernel works best in many situations. As stated, it only loads what is autodetected or what is enabled via the rc.modules startup script, however I have yet to edit rc.modules since 13.0 as everything now works mostly without the need for it. Anything else I load via rc.local.
What do you find "too modular" about the generic kernel? The linux kernel seems bloated enough, the more stuff you can keep out of it the better.
Mostly trivial stuff. I still don't understand the point of the CONFIG_BLK_DEV_LOOP=m change, especially with the addition of the rc.loop file that introduced (which i find a little ugly). But that wasn't really my point. My point was that huge or generic give you an all or nothing situation and most users will find themselves somewhere in between (but closer to the generic end of the scale).
Suddenly I remembered reading the Slackware Release Announcement...
Quote:
Slackware's Linux kernels come in both SMP and non-SMP types now. The SMP kernel supports multiple processors, multi-core CPUs, HyperThreading, and about every other optimization available. In our own testing this kernel has proven to be fast, stable, and reliable. We recommend using the SMP kernel even on single processor machines if it will run on them.
So I let loose my creative side and instead of configuring lilo with the generic 2.6.37.6 for which I had just created the initrd I threw in the generic 2.6.37.6 smp kernel.
I was in for a little surprise when I rebooted the machine.
Not even my keyboard seemed to work, that was slightly bad news.
Well at least I recognized where the error was made and after some reinstalling of the original lilo config using the Slackware DVD I could gain access again to the system with the huge kernel I used before.
I built a new initrd suited for the generic 2.6.37.6 smp kernel and after reconfiguring lilo appropriately it all worked nicely.
For now I gained about 4 seconds while booting Slackware. (yay)
There are two reasons I do this:
1. The Kernels with all of the relevant modules required to boot, became too big to actually boot (the boot loader wouldn't boot it!)
2. The initrd's are for a very specific ARM device where I know that I'm providing what is necessary to get that system booted.
The same cannot be said for an x86.
However, even on the 'kirkwood' initrd's, there are modules loaded for some hardware (e.g. a soundcard) that doesn't exist on all of the systems upon which this initrd can be used which wastes RAM and should be modprobe -r'd.
I built a new initrd suited for the generic 2.6.37.6 smp kernel and after reconfiguring lilo appropriately it all worked nicely.
I have a Core 2 Duo in my machine. Do I need the SMP for that, or is it covered by the general kernel? Did you have to load any specific modules that differed from a generic initrd setup?
(I'm new to Slackware, and I'm not even sure where to get these SMP kernels. They weren't installed to /boot by default, but I haven't looked on the install media yet, either. This is a project for next weekend, anyway.)
To initrd or not to initrd? Short answer: why not, if it's the recommended way to go, and not a big deal? On a fresh install, making an initrd takes about two minutes.
Code:
# cd /etc
# mv mkinitrd.conf.sample mkinitrd.conf
Edit the relevant lines in mkinitrd.conf. I always find that easier than to remember a load of command-line switches. When you're finished:
Code:
# mkinitrd -F
Now edit Lilo to boot on the generic kernel and to use the newly created initrd. Don't forget:
I have a Core 2 Duo in my machine. Do I need the SMP for that, or is it covered by the general kernel?
The "Duo" in the name tells you it has two processor cores, whilst "Core 2" refers to Intel's consumer 64-bit x86-64 processors (hence a processor labelled simply Core Duo, would be a 32-bit processor). For more, read: http://en.wikipedia.org/wiki/Intel_Core
Remember the Slackware release announcement quoted above states "The SMP kernel supports multiple processors, multi-core CPUs, ....". So yes this is the one you want. As for generic, the SMP kenels come in generic and huge format, meaning Slackware actually provides 4 kernel options huge, huge+smp, generic and generic+smp. You want the last one.
Quote:
Originally Posted by jrhorn424
(I'm new to Slackware, and I'm not even sure where to get these SMP kernels. They weren't installed to /boot by default, but I haven't looked on the install media yet, either. This is a project for next weekend, anyway.)
The are pre-installed by default if you did a full install (and if you are new to Slackware you really should have done that). On my 13.37 system the generic SMP kernel is here: /boot/vmlinuz-generic-smp-2.6.37.6-smp. If it isn't on yours, install kernel-generic-smp via slackpkg and also make sure you have kernel-modules-smp installed as well. To setup read README.initrd from the install disk.
I have a Core 2 Duo in my machine. Do I need the SMP for that, or is it covered by the general kernel? Did you have to load any specific modules that differed from a generic initrd setup?
(I'm new to Slackware, and I'm not even sure where to get these SMP kernels. They weren't installed to /boot by default, but I haven't looked on the install media yet, either. This is a project for next weekend, anyway.)
I'd just like to note that if you are running Slackware 64 there is no need for the SMP kernel as all kernels that is comes with are SMP capable.
I'd just like to note that if you are running Slackware 64 there is no need for the SMP kernel as all kernels that is comes with are SMP capable.
Thanks, I am running 64. The reason I asked is because none of the files installed to /boot (vmlinuz-generic*, for example) have SMP anywhere in the filename. Your comment suggests SMP is implied for 64 bit systems.
The system seems fast enough anyway, but if I was underutilizing my CPU, I would like to have known. Thanks for clearing it up.
Do'h. I didn't even consider he might be running on 64-bit, which was silly of me given he has a 64-bit processor.
Not that silly
I'm running 32bit Slackware 13.37 on 64bit capable hardware.
I hadn't used a Linux OS for a while and I just didn't want to start off with a multilib system to keep things less complicated while getting back "into it".
So I just chose 32bit for now to be able to use wine / virtualbox etc...
I guess after reading the information below that 64bit is still not an option if you want to use certain applications.
I will give some examples of programs that require multilib support on a 64bit Slackware because they will not start or compile on Slackware64 without the 32bit compatibility layer:
Wine
Most Windows programs are still 32bit, and in order to run those on Linux with Wine, you need a 32bit version of Wine.
VirtualBox
The popular virtual machine software. Although this is (partly) open source it still needs 32-bit compatibility libraries on 64-bit Slackware.
Skype, Citrix client, …
These programs are proprietary and closed-source. We have to depend on the developer to make 64bit binaries available. So far, that has not happened for these example programs.
Luckily, 64bit support is becoming more and more common. In the past year, Adobe released their Flash browser plugin in a 64bit version and Sun revealed a 64bit version of their Java browser plugin. This was one of the triggers to start working on Slackware64.
The silly part was my response to jrhorn424, where I told him that he should have vmlinuz-generic-smp-2.6.37.6-smp if he did a full install. However, there is no kernel-generic-smp package for Slackware64 and given he has a 64-bit processor I should have guessed he might be using Slackware64. So in summary what I said was just plain wrong! Hence the D'oh.
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
Rep:
Quote:
So I just chose 32bit for now to be able to use wine / virtualbox etc...
Just to let you know - the following is incorrect now :
Quote:
VirtualBox
The popular virtual machine software. Although this is (partly) open source it still needs 32-bit compatibility libraries on 64-bit Slackware.
I run straight Slackware64 (no multilib) and VirtualBox works fine. Wine is still a problem though so I just run 32bit Windows in VirtualBox when I need.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.