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've read a few topics and readme's concerning building an initrd for Slackware 13.37.
For example this part from the Slackware Release Announcement ...
Quote:
...First there are the huge kernels, which contain support for just about every driver in the Linux kernel. These are primarily intended to be used for installation, but there's no real reason that you couldn't continue to run them after you have installed. The other type of kernel is the generic kernel, in which nearly every driver is built as a module. To use a generic kernel you'll need to build an initrd to load your filesystem module and possibly your drive controller or other drivers needed at boot time, configure LILO to load the initrd at boot, and reinstall LILO...
It seems clear to me that there isn't a big reason ("there's no real reason that you couldn't continue to run them after you have installed") to switch from huge to generic but can someone elaborate on the consequences (performance / stability / ...) for a Slackware system that uses huge vs generic ?
I'm interested in learning a bit more about the possible advantages and disadvantages of both.
I'm still not really sure why I should make an initrd or not.
Maybe you can help me decide
Thanks
Click here to see the post LQ members have rated as the most helpful post in this thread.
I've never really used or needed initrd on my system. It's only really useful if you need to preload modules like ReiserFS and such for boot process purposes. Other than that, the system can fairly much load everything else on it's own. I stopped using ReiserFS when I came to Slackware as my main Linux OS choice and started using EXT4 so I've been without an initrd for a long time now. It's a handy thing to have if you need it, but if you don't, it's just unneeded.
A reason for using the generic kernels is that the Slackware team will only take seriously bugs that can be replicated using those. A reason not to use them is if you use slackpkg to update your kernels and don't want to rebuild the initrd and run lilo manually all the time your kernel is updated.
I don't really like the 'huge' or 'generic' approach slackware uses. IMO 'huge' contains too much stuff, and 'generic' pushes too much stuff out to modules. There must be a happy medium somewhere in-between, and to that end I build my own kernel.
As for performance and stability, I doubt you'd be able to detect any difference, though there have been posts on this forum from time to time where someone running a 'huge' kernel has encountered problems that switching to the generic kernel resolved (Usually related to trying to build or use out-of-tree drivers).
A initrd is required in certain circumstances: such as having your rootfs on encrypted devices or a raid array that needs assembling. I have my rootfs on an encrypted lvm partition so even though I use a custom kernel, I still need a initrd because of this.
Thank you all for your answers. At the time being I don't seem to have a real need to change kernels. Maybe I'll try it out sometime just to see how it goes.
I find the utility of a 'initrd' to be beneficial when you have multiple systems that are unique environemts and the facility of the 'initrd' very useful.
There have been unique systems that performed better with a 'initrd' than having things compiled in. Two phased control can be useful when one has to use a kernel that requires additions for functionality. I do tend to move to the generic, easier to trim the fat thus a 'initrd'. If a trim then re-compile work from there.
Distribution: Ubuntu 11.4,DD-WRT micro plus ssh,lfs-6.6,Fedora 15,Fedora 16
Posts: 3,233
Rep:
Quote:
Originally Posted by noobje
How about a custom kernel without the "bloat" but with the stuff that initrd normally takes care off ?
Instead of an initrd + generic kernel...
doable,especially if you're the one compiling the kernel as machines differ thus so do drivers. I could be wrong but i believe initrd is generated as a subset of LOADED modules.
The generic kernel with an initrd is easier to upgrade. If you follow -current and the kernel is upgraded, then you can download and install the new generic kernel together with the modules, run mkinitrd, reboot and be running the new kernel very quickly.
A custom kernel avoids the need for an initrd, but will require recompilation if the kernel is upgraded, a longer and more involved process.
... I could be wrong but i believe initrd is generated as a subset of LOADED modules.
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 ?
I don't really like the 'huge' or 'generic' approach slackware uses. IMO 'huge' contains too much stuff, and 'generic' pushes too much stuff out to modules. There must be a happy medium somewhere in-between, and to that end I build my own kernel.
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.
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 ?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.