Initrd: Difference between revisions

The term initrd stands for "initial ramdisk". Basically, it is simply a file loaded into memory which the OS uses as a filesystem containing stuff necessary for it to boot.

Uses of an initrd

Usually, initial ramdisks are used by Modular Kernels and Microkernels, which commonly face a chicken-or-egg problem at boot time: the kernel needs to load its modules from disk, but these modules include the driver that normally allows the kernel to access that disk (although this applies to any other media). An initrd is an elegant solution to this problem: the boot disk driver is stored within the initrd, which is loaded along with the kernel. Then, when the kernel boots, it retrieves the initrd in memory, loads the boot disk driver from it, and uses the freshly loaded driver to load the rest of its modules. This is the solution used by Linux (not the early versions), as well as many hobby OSes.

Setting up an initrd

An initrd is simply a file containing some sort of minimalistic filesystem (if it can be called so). Such a filesystem totally depends on the operating system and its version, but is usually some archive format (compressed or not) such as tar, which has the advantage of being very simple to generate using the tar command, a simplistic filesystem such as SFS, or just a custom format. The good news is that this custom filesystem can be very simple: in fact, it doesn't need the complications of usual filesystems, such as addition, modification or deletion of files, and the parsing logic can be very simple.

Setup in a multiboot-compliant kernel

If you are using a Multiboot-compliant kernel, then most of the job is already performed by your bootloader (e.g. GRUB). All you have to do is tell the bootloader to load the initrd along with your kernel as a Multiboot module (for GRUB, this setting is found in grub.cfg), and use the Multiboot structure to find where it has been loaded.

A GRUB script would look similar to this:

menuentry "myos" {
	multiboot /boot/myos.bin
	module /boot/myos.initrd
}

Setup in custom-booted kernels

If you are using a custom bootloader, then you will have to load the initrd yourself. You can either load it at a fixed address and hardcode it into the kernel, or determine that address dynamically, and pass it to the kernel.

As an alternative, you can use the cat command to concatenate your kernel image and initrd image, and modify the linker script to setup a constant as the ending address of your kernel, which will match the loading address of your initrd, or just write a simple program to convert your initrd image into a C header containing a byte array containing its bytes, and include that into your kernel.

Alternatives

If you can't (or just don't want to) use an initrd, you can also use a reserved boot partition (which is much the same thing, except you'll need the disk driver before), or just build certain modules directly into the kernel, which might be a bad idea because changing filesystem or disk will require the kernel to be recompiled with different modules, unless you prefer to hard-build several disk drivers into your kernel, which will increase boot time.

The article on Modular Kernels shortly describes some other alternative solutions.

See Also

Articles

• tar archive format
• SFS — simple filesystem implementation
• BOOTBOOT loader that can load tar, cpio, James Molloy's and SFS initrds

External Links

• cpio archive format
• SquashFS — filesystem designed for small disks
• CramFS — filesystem designed for compressed ram disks

• Pages using duplicate arguments in template calls
• Filesystems
• Booting