SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
i added all ram disk sections into the kernel (compiled in). i just wanted to verify, it's still optional to use initrd with that, right or is it required to use if compiled in? i'd expect it to be optional but having trouble booting my 2.6.x kernel.
For my part I used to compile initrd feature (virtual ram disk etc) in kernel, but I never used it yet (no reason for that). The kernel boot fine without initrd although feature is compiled as built-in (2.6.7 kernel), so if you have problem to boot it, I think the error does not come from initrd.
I think RedHat, Mandrake, SuSE do initrd for load many modules at boot to detect a maximum various hardware and filesystem without compile all in the kernel as built-in (to reduce kernel file size), If you look at redhat .config file for kernel, nearly all the features are enabled (maybe to obtain a sort of plug and play system, I don't know)
Yes, those distros prefer to build nearly everything as modules; what you need to put inside the initrd are just those modules that are neccesary to be able to mount the root filesystem (eg. ext3, or scsi card drivers).
Because, imagine you need to load the driver for your scsi card, in order to mount the root fs... but that module is in /lib/modules, *ON* your root fs, which is not mounted yet --> deadlock!
You don't have to use it just because it's compiled in-. Have a study at rdev to see where you may have problems though.
initrds are great, try running a slack install without one!
Where slackware provides pre-compiled kernels for unusual hardware support the other distros will provide an initrd that lets you load a module from a floppy during boot-up. Then, when installed you create a custom initrd to install your needed modules. this ability is needed for 2.6.x because of kernel size, which limits the ability to include compiled-in support.
what i think is that initrds are used only during startup
they are of no use afterwards
so compiling then in the kernel and getting kernel bigger ,doesn't it decrease the performance with the case where we do not have the initrd along with the kernel
Originally posted by masand so compiling then in the kernel and getting kernel bigger ,doesn't it decrease the performance with the case where we do not have the initrd along with the kernel
it might make it slightly bigger but i don't think it decreases performance on the kind of machines there are. i don't mean the high end ones. i doubt it'd make a big diff even on a 120/133 MHz. it might just take up more space in ram.
on the other hand, things like unneccesary device drivers and debugging capability compiled into the kernel is the cause of significant performance hit. debugging is not bad, but if u don't use it, u're *not* using an active kernel feature.