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 Initial Ramdisk

Initial Ramdisks are usually 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 OS's.

Setting up an Initial Ramdisk

An initrd is simply a file containing some sort of minimalistic filesystem (if it can be called so). That filesystem totally depends on the Operating system and its version, but it 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 has to be very simple: you don't want your kernel to spend 5 minutes reading the initrd on each boot, do you ? JamesM's tutorials describe the development of a VFS and of an initrd.

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 GRUB to load it along with you kernel, as a Multiboot module (for GRUB, the setting is found in menu.lst for GRUB Legacy, or grub.cfg for GRUB2), and use the Multiboot structure to find where it has been loaded.

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 the kernel, which will increase boot time.

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

See Also

• tar archive format
• SFS simple filesystem implementation

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