Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
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 know that an initial ramdisk contains drivers and modules required for accessing hardware before the root partition can be mounted. If the initial ramdisk is stored on the root partition, then how is it accessed, if the initial ramdisk is required to mount the root partition? Wouldn't statically compiling the drivers required for accessing the root partition defeat the purpose of the initial ramdisk?
The initrd is not ALWAYS required in order to access the root partition. Most initrds are not required at all. I think that distribution developers put them in there just to make it easier to create a system where an initrd IS required.
The only time that you really need an initrd is when the boot loader cannot directly load the Linux kernel. These situations include
1) using an encrypted root partition
2) using a software or fake RAID device for the root partition
That's it. If your system does not use either of the two mentioned characteristics then you don't really need an initrd. Your boot loader could just boot the Linux kernel image.
As to your second question,
If the initial ramdisk is stored on the root partition, then how is it accessed, if the initial ramdisk is required to mount the root partition?
In these cases the initrd must reside on a partition that can be accessed by the boot loader software. That is why you can specify a different partition for the /boot directory. If your root partition is on a software RAID partition then your /boot partition must be on a non-RAIDed partition. If your root partition is encrypted then your /boot partition must reside on an unencrypted partition.
(The initrd generally resides in /boot.)
That's basically it.
Last edited by stress_junkie; 12-30-2010 at 03:36 PM.
If the initial ramdisk is stored on the root partition, then how is it accessed, if the initial ramdisk is required to mount the root partition? Wouldn't statically compiling the drivers required for accessing the root partition defeat the purpose of the initial ramdisk?
The initrd image can be read from the drive because it isn't done by the kernel, the boot loader does it. The kernel can load modules from the initrd environment because it has already been read into memory.
An initrd is optional. Most things you can compile directly into the kernel. If you compiled your own kernel and compiled modules for your hardware and file system direct then you can do away with your initrd.
I think most distros compile a small kernel and use initrds because generating an initrd with the required drivers is quite fast, recompiling the kernel to include the support directly is very slow. For most distros, you will need the initrd to boot your system using the default kernel.
On the other hand, I can't remember software RAID and the encryption stuff as modules only, meaning that you can probably compile them direct and do away with the initrd even with an encrypted file system or software RAID. However, it has been 4 or 5 years since I last compiled a kernel.
I'm probably wrong on the encryption front, but only because the initrd will have shell scripts for prompting for the passphrase and unlocking the drive. The actual kernel modules may still be able to be compiled directly
if the modules you need to boot the system are compiled into the kernel you do not need an initial ram disk. However, generic kernels with everything compiled as modules do not function this way. Generally you custom build a kernel to avoid an initial ram disk.
If you use encrypted partitions, you need an initial ramdisk that will allow you to unlock the partitions before it continues with the boot up.
I think it would be interesting to see what happens if you packed a GUI along with all its dependencies into the initrd and then hard-code it into the "init" script in its top level directory as such that it runs in kernel space without a problem.
I don't think it's as much about load time as having a small kernel.
Without an initrd, all the drivers for all supported systems that are necessary to access the root filesystem must by build in (the kernel can't find modules until a filesystem is mounted with the modules on it). This will create an unnecessarily large kernel, using up excess RAM while the machine runs.
By using an initrd, after the initial boot, before much else is loaded, the initrd is discarded and the kernel is as small as possible.
An initrd is also necessary if you're dealing with a root filesystem that the kernel cannot mount on its own, such as an encrypted volume (you need a userspace to ask for the password) or a loopback-mounted root filesystem sitting on another filesystem (like Ubuntu's Wubi).