Slashdot Mirror
Discover the Anatomy of initrd
IdaAshley writes "The Linux initial RAM disk (initrd) is a temporary root file system that is mounted during system boot to support the two-state boot process. It contains various executables and drivers that permit the real root file system to be mounted, after which the initrd RAM disk is unmounted and its memory freed. In this article explore the initial RAM disk for Linux 2.6, including its creation and use in the Linux kernel. In many embedded Linux systems, the initrd is the final root file system."
This looks to be a pretty good tutorial.
As well as mkinitrd, there are some cool tools coming along that help build an initrd.
Here is one I have used, and although it's very early in it's development cycle.
http://yaird.alioth.debian.org/
Are there any more that are actually easy to use?
Signature v3.0, now with 42% less memory usage.
Is it just me, or does maintaining initrd seem like more trouble than it is worth? I guess it is good for generic distributions which want to support every hardware config under the sun and keep the kernel small, but if you know the (set of) hardware you are going to be running a given kernel on, you might as well just blow that initrd crap away. Whenever I recompile a kernel, initrd is the first thing to go. All you need in the kernel to make initrd irrelevent is disk and filesystem (and maybe software RAID modules) support. You can keep everything else as modules.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Stick to our techie roots.
We want more politics, thinly disguised corporate press releases, and pseudoscience articles, please!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
You're right. Initramfs is better in many ways to initrd, and doesn't have the crazy limitations.
Initramfs, IIRC, has these advantages:
It doesn't need block level drivers compiled into the kernel to read itself like initrd does.
It uses the kernel cache area as its file storage area so you don't have to allocate space with a ramdisk.
The mem it used to store files with temporarily can be returned to the kernel after the kernel has booted.
No artificial size limit.
All in all, it's a much better alternative.
There are definitely times where it is required.
Take, for example, booting onto a root on a SAN--specifically a Coraid Ethernet SAN.
During boot, you must bring up the ethernet interface, load the AoE module, probe for the SAN, wait for it to quiesce, then enable clustering, join the cluster, join the fence domain, allow the cluster to quiesce, load the DLM, enable CLVM, probe and activate everything, then mount your root GFS (or OCFS2 if you can get that working).
This would not be possible without a good initrd.
Also, not so obviously, distros aren't the only people who deploy a single kernel on lots of hardware. When you have 300 old Dells, 150 old gateways, 75 custom built boxen, and a handful of laptops, maintaining a single kernel and initrd beats maintaining ten of them. Not your use case, but definitely important.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
I don't know much about this, but am curious.
Why, once the system is booted cleanly, can't it save its state in initrd, and just load the state the next time without going through the boot process? Would that result in fast booting?