Slashdot Log In
Discover the Anatomy of initrd
Posted by
timothy
on Thu Aug 03, 2006 12:38 PM
from the oh-you-clever-pr-people dept.
from the oh-you-clever-pr-people dept.
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 discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Great tutorial (Score:5, Informative)
(http://www.headfuzz.co.uk/ | Last Journal: Sunday November 26 2006, @08:49PM)
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/ [debian.org]
Are there any more that are actually easy to use?
More trouble... (Score:4, Interesting)
-matthew
Nontrivial Boot Environments (Score:4, Interesting)
(http://souja.net/)
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.
Initramfs? (Score:3, Interesting)
(http://www.baumanfamily.com/john/)
Re:Initramfs? (Score:5, Informative)
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.
More More More!!! (Score:5, Insightful)
Stick to our techie roots.
F*ck that, give us more politics! (Score:4, Funny)
(Last Journal: Tuesday August 07, @01:18PM)
Options for fast booting (Score:5, Interesting)
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?
Do not use those instructions! (Score:2)
(http://www.linuxlabs.com)
Unfortunatly, the article starts well by explaining initramfs (using a compressed cpio rather than a block device image), but then leads the reader down the initrd path.
Initramfs is intended to superceed initrd for several good reasons.
For one, it's more efficient. Files in an initramfs are a special case of filesystem where the file is loaded into the generic file cache but has no backing storage (that is, it doesn't live on a block device). OTOH, an initrd is a simple image of a block device. It has a fixed number of blocks defined at creation time. On top of that it has filesystem formatting.
For one thing, access to the file takes a much simpler path through the code in the case of initramfs. At a minimum, an initrd requires one more filesystem to be built in to the kernel. Initramfs itself is just a thin layer over the generic filesystem code, so is much smaller and simpler.
An initramfs image will be exactly the size that is needed, never more or less. There is no need to guess what size block device will be needed to exactly hold everything you need in advance. There is no need to go with anything larger 'just in case'.
As for memory usage, once an initramfs is mounted, if you rm a file, that memory is immediatly freed (assuming nothing is holding the file open). With initrd, you can rm a file but it won't help you, it just means you now have more wasted blocks held in RAM.
Initramfs can grow as necessary (memory permitting). For example if the boot process fails, you can log WHY to a file and drop to a root shell for debugging. An initrd can be writable, but can never be any larger than it was created to be. If you MIGHT need to write, you will have to build the initrd large enough to cover the worst case anyone might encounter in debugging and hope that's not too big for machines with less RAM to accomodate.
Once you get a swap partition mounted from somewhere, your initramfs can be swapped out as needed, so can grow larger than RAM if necessary. With an initrd, it's stuck right where it is until you unmount it.
It seems to me that the reasons to keep the old initrd support around are down to support for legacy uses and as long as we have the code and it's not too much trouble, why not?
So, in the shell script from the article, instead of creating /tmp/ramdisk.img and mounting it with -oloop, just create a directory and copy (or hardlink) what you want more or less as the script does. Then make a compressed cpio archive of it as the initramfs image. Possibly like cd initrd; find . |cpio -H newc -o |gzip -9 >../initrd.img.gz
Re:OMFG! (Score:1, Offtopic)