dracut 105

Most Linux distributions ship a single, generic kernel image that is intended to boot a wide variety of hardware. The device drivers for this generic kernel image are included as loadable modules, as it is not practical to statically compile them all into the one kernel without making it excessively large. However, this then raises the problem of detecting and loading the device driver modules necessary to mount the root file system at boot time (or, for that matter, deducing where or what the root file system is).

To further complicate matters, the root file system may be on a software RAID volume, LVM, NFS (on diskless workstations), or on an encrypted partition. All of these require special preparations to mount. Another complication is kernel support for hibernation, which suspends the computer to disk by dumping an image of the entire system to a swap partition or a regular file, then powering off. On next boot, this image has to be made accessible before it can be loaded back into memory.

To avoid having to hardcode many special cases into the kernel, an initial boot stage with a temporary root file system — now dubbed early user space — is used. This root file system contains user-space helpers that do the hardware detection, module loading and device discovery necessary to get the "real" root file system mounted, which the kernel then "pivots" onto to continue the boot process.

An image of this initial root file system (along with the kernel image) must be stored somewhere accessible by the Linux bootloader or the boot firmware of the computer. This is usally partition on a local disk (a boot partition) or perhaps remotely via a TFTP server (on systems that can boot from Ethernet). The bootloader will load the kernel and initial root file system image into memory and then start the kernel, passing in the memory address of the image.

initrd and initramfs are two related but different methods of creating the early user space environment. Both achieve similar goals of allowing the kernel to find the main root device, but operate differently.

In short, initrd is a block device image, while an initramfs is a cpio archive that the kernel extracts to a temporary file system created at boot. The difference is subtle but important to many of the internal operations of kernel initalization; for more details see kernel rootfs documentation.

While the initrd approach is essentially obsolete, you may still see references to it; confusingly the terms are sometimes used interchangeably.

dracut creates initramfs archives.

dracut creates an initrd image by copying tools and files from an installed system and combining it with dracut modules, usually found on an installed system in /usr/lib/dracut/modules.d.

Unlike other implementations, dracut hard-codes as little as possible into the initramfs. To keep the time required in the initramfs as little as possible, instead of scripts hard-coded to do various things, dracut depends on on udev to create device nodes. When the rootfs’s device node is available, we mount and carry on.

Most of the initramfs generation functionality in dracut is provided by generator modules that are sourced by the main dracut script to install specific functionality into the initramfs. They live in the modules.d subdirectory, and use functionality provided by dracut-functions to do their work.

dracut’s initramfs starts only with the device name of the root file system (or its UUID) and must discover everything else at boot time. A complex cascade of tasks must be performed to get the root file system mounted:

dracut uses udev, an event-driven hotplug agent, which invokes helper programs as hardware devices, disk partitions and storage volumes matching certain rules come online. This allows discovery to run in parallel, and to progressively cascade into arbitrary nestings of LVM, RAID or encryption to get at the root file system.

When the root file system finally becomes visible:

The final root file system cannot simply be mounted over /, since that would make the scripts and tools on the initial root file system inaccessible for any final cleanup tasks. On an initramfs, the initial root file system cannot be rotated away. Instead, it is simply emptied and the final root file system mounted over the top.

If the systemd module is used in the initramfs, the ordering of the services started looks like DRACUT.BOOTUP(7).

Dracut can operate in two modes

On a systemd driven system, the dracut initramfs is also used for the shutdown procedure. See DRACUT-SHUTDOWN.SERVICE(8) for details.

Issues and merge requests can be found at the GitHub development page at https://github.com/dracut-ng//dracut-ng

dracut (pronounced: /ˈdreɪkət/) was the initial brainchild born out of late night scheme of Farce Majeure, Jeremy Katz and Dave Jones who also did the initial implementation until Harald Hoyer took it under his care in 2009 and continued its development from there on.

The project started and was announced in 2008.

Some people inside Red Hat started to name their projects after cities and villages around the developer headquarters of Red Hat in Westford, Massachusetts.

So, dracut is named after the town Dracut, similar to Wayland and Weston.

dracut is licensed under the GNU General Public License (GPL) v2; see COPYING

Parts of this documentation site are taken from work licensed under the Creative Commons Attribution/Share-Alike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.