Initramfs

An initramfs is a filesystem loaded in memory during the early boot process. Therefore, some utilities, kernel modules, scripts, ..., may be used during the boot process. The initramfs usually takes care of mounting important file systems (by loading the proper kernel modules and drivers) such as or, preparing the  file structure, etc. Users who use an encrypted file system will also have the initramfs ask them for the passphrase before it can mount the file systems. When the file systems are mounted, control is passed on to init which then takes care of further starting all necessary services and booting up the remainder of the system.

Initramfs concepts
For many users, an initramfs system is of no concern. Their system uses a simple partitioning schema with no exotic drivers or setups (like encrypted file systems), so the Linux kernel is entirely capable to hand over control to the binary on their system. But for many systems, an initramfs is mandatory.

The key concept to understanding what an initramfs is (or is needed for) is to understand how the Linux boot process works, even in a high-level approach.

Linux boot process
Once the Linux kernel has control over the system (which it gets after being loaded by the boot loader), it prepares its memory structures and drivers. It then hands over control to an application (usually ) whose task it is to further prepare the system and make sure that, at the end of the boot process, all necessary services are running and the user is able to log on. The application does that by launching, among other services, the  daemon who will further load up and prepare the system based on the detected devices. When is launched, all remaining file systems that have not been mounted are mounted, and the remainder of services is started.

For systems where all necessary files and tools reside on the same file system, the application can perfectly control the further boot process. But when multiple file systems are defined (or more exotic installations are done), this might become a bit more tricky:


 * When the partition is on a separate file system, tools and drivers that have files stored within  cannot be used unless  is available. If those tools are needed to make  available, then we cannot boot up the system.


 * If the root file system is encrypted, then the Linux kernel will not be able to find the application, resulting in an unbootable system.

The solution for this problem has since long been to use an initrd (initial root device).

The initial root disk
The initrd is an in-memory disk structure (ramdisk) that contains the necessary tools and scripts to mount the needed file systems before control is handed over to the application on the root file system. The Linux kernel triggers the setup script (usually called but that name is not mandatory) on this root disk, which prepares the system, switches to the real root file system and then calls.

Although the initrd method is all that is needed, it had a few drawbacks:


 * It is a full-fledged block device, requiring the overhead of an entire file system; it has a fixed size. Choosing an initrd that is too small and all needed scripts cannot fit. Make it too big and memory will be wasted.


 * Because it is a real, static device it consumes cache memory in the Linux kernel and is prone to the memory and file management methods in use (such as paging), this makes initrd greater in memory consumption.

To resolve these issues the initramfs was created.

The initial ram file system
An initramfs is an initial ram file system based on tmpfs (a size-flexible, in-memory lightweight file system), which also did not use a separate block device (so no caching was done and all overhead mentioned earlier disappears). Just like the initrd, it contains the tools and scripts needed to mount the file systems before the binary on the real root file system is called. These tools can be decryption abstraction layers (for encrypted file systems), logical volume managers, software raid, bluetooth driver based file system loaders, etc.

The content of the initramfs is made by creating a cpio archive. is an old (but proven) file archiver solution (and its resulting archive files are called cpio files). cpio is definitely comparable to the archiver. The choice of here was because it was easier to implement (code-wise) and supported (back then) device files which  could not.

All files, tools, libraries, configuration settings (if applicable), etc. are put into the cpio archive. This archive is then compressed using the utility and stored alongside the Linux kernel. The boot loader will then offer it to the Linux kernel at boot time so the kernel knows an initramfs is needed.

Once detected, the Linux kernel will create a tmpfs file system, extract the contents of the archive on it, and then launch the script located in the root of the tmpfs file system. This script then mounts the real root file system (after making sure it can mount it, for instance by loading additional modules, preparing an encryption abstraction layer, etc.) as well as vital other file systems (such as and  ).

Once the root file system and the other vital file systems are mounted, the script from the initramfs will switch the root towards the real root file system and finally call the  binary on that system to continue the boot process.

Building an initramfs
Several ways :
 * Early Userspace Mounting
 * Dracut
 * Genkernel
 * Mkinitcpio
 * mkinitramfs-ll, sys-kernel/mkinitramfs-ll
 * Custom Initramfs