Confused over how initial ramdisks work
Hello,
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? Thanks! |
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, Quote:
(The initrd generally resides in /boot.) That's basically it. |
Quote:
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. EDIT 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.
HOWEVER, 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.
|
Thanks, everyone, for the informative replies!
So now my understanding is that initrds are a way to quickly load drivers and modules for the kernel, faster than it would be if statically compiled. Is this more or less correct? |
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). I hope this clears things up. |
|
All times are GMT -5. The time now is 11:48 AM. |