Table of Contents
Table of Contents
This section is a modified version of http://en.wikipedia.org/wiki/Initrd which is licensed under the Creative Commons Attribution/Share-Alike License.
An initial ramdisk is a temporary file system used in the boot process of the Linux kernel. initrd and initramfs refer to slightly different schemes for loading this file system into memory. Both are commonly used to make preparations before the real root file system can be mounted.
Many Linux distributions ship a single, generic kernel image that is intended to boot as wide a variety of hardware as possible. The device drivers for this generic kernel image are included as loadable modules, as it is not possible to statically compile them all into the one kernel without making it too large to boot from computers with limited memory or from lower-capacity media like floppy disks.
This then raises the problem of detecting and loading the 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 handling for so 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 would contain user-space helpers that would do the hardware detection, module loading and device discovery necessary to get the real root file system mounted.
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 can be:
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.
Depending on which algorithms were compiled statically into it, the kernel can currently unpack initrd/initramfs images compressed with gzip, bzip2 and LZMA.
dracut can generate a customized initramfs image which contains only whatever is necessary to boot some particular computer, such as ATA, SCSI and filesystem kernel modules (host-only mode).
dracut can also generate a more generic initramfs image (default mode).
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:
If the root file system is on NFS, dracut does then:
If the root file system is on an encrypted block device:
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 Chapter 12, DRACUT.BOOTUP(7).
On a systemd driven system, the dracut initramfs is also used for the shutdown procedure.
The following steps are executed during a shutdown:
This ensures, that all devices are disassembled and unmounted cleanly.
Table of Contents
Table of Contents
Create an initramfs <image> for the kernel with the version <kernel version>. If <kernel version> is omitted, then the version of the actual running kernel is used. If <image> is omitted or empty, the default location will be determined by the local configuration or Linux distribution policy.
dracut creates an initial image used by the kernel for preloading the block device modules (such as IDE, SCSI or RAID) which are needed to access the root filesystem, mounting the root filesystem and booting into the real system.
At boot time, the kernel unpacks that archive into RAM disk, mounts and uses it as initial root file system. All finding of the root device happens in this early userspace.
Initramfs images are also called "initrd".
For a complete list of kernel command line options see dracut.cmdline(7).
If you are dropped to an emergency shell, while booting your initramfs, the file /run/initramfs/rdsosreport.txt is created, which can be saved to a (to be mounted by hand) partition (usually /boot) or a USB stick. Additional debugging info can be produced by adding rd.debug to the kernel command line. /run/initramfs/rdsosreport.txt contains all logs and the output of some tools. It should be attached to any report about dracut problems.
To create a initramfs image, the most simple command is:
# dracut
This will generate a general purpose initramfs image, with all possible
functionality resulting of the combination of the installed dracut modules and
system tools. The image contains the kernel modules of
the currently active kernel with version <kernel-version>.
The default location of the image is determined by the local configuration
or Linux distribution policy.
If the initramfs image already exists, dracut will display an error message, and to overwrite the existing image, you have to use the --force option.
# dracut --force
If you want to specify another filename for the resulting image you would issue a command like:
# dracut foobar.img
To generate an image for a specific kernel version, the command would be:
# dracut foobar.img 2.6.40-1.rc5.f20
A shortcut to generate the image at the default location for a specific kernel version is:
# dracut --kver 2.6.40-1.rc5.f20
If you want to create lighter, smaller initramfs images, you may want to specify the --hostonly or -H option. Using this option, the resulting image will contain only those dracut modules, kernel modules and filesystems, which are needed to boot this specific machine. This has the drawback, that you can’t put the disk on another controller or machine, and that you can’t switch to another root filesystem, without recreating the initramfs image. The usage of the --hostonly option is only for experts and you will have to keep the broken pieces. At least keep a copy of a general purpose image (and corresponding kernel) as a fallback to rescue your system.
To see the contents of the image created by dracut, you can use the lsinitrd tool.
# lsinitrd | less
To display the contents of a file in the initramfs also use the lsinitrd tool:
# lsinitrd -f /etc/ld.so.conf include ld.so.conf.d/*.conf
Some dracut modules are turned off by default and have to be activated manually. You can do this by adding the dracut modules to the configuration file /etc/dracut.conf or /etc/dracut.conf.d/myconf.conf. See dracut.conf(5). You can also add dracut modules on the command line by using the -a or --add option:
# dracut --add module initramfs-module.img
To see a list of available dracut modules, use the --list-modules option:
# dracut --list-modules
Sometimes you don’t want a dracut module to be included for reasons of speed, size or functionality. To do this, either specify the omit_dracutmodules variable in the dracut.conf or /etc/dracut.conf.d/myconf.conf configuration file (see dracut.conf(5)), or use the -o or --omit option on the command line:
# dracut -o "multipath lvm" no-multipath-lvm.img
If you need a special kernel module in the initramfs, which is not automatically picked up by dracut, you have the use the --add-drivers option on the command line or the drivers variable in the /etc/dracut.conf or /etc/dracut.conf.d/myconf.conf configuration file (see dracut.conf(5)):
# dracut --add-drivers mymod initramfs-with-mymod.img
An initramfs generated without the "hostonly" mode, does not contain any system configuration files (except for some special exceptions), so the configuration has to be done on the kernel command line. With this flexibility, you can easily boot from a changed root partition, without the need to recompile the initramfs image. So, you could completely change your root partition (move it inside a md raid with encryption and LVM on top), as long as you specify the correct filesystem LABEL or UUID on the kernel command line for your root device, dracut will find it and boot from it.
Generic initrd’s are larger, but should be able to automatically boot any bootable configuration with appropriate boot flags (root device, network configuration information, etc.)
The kernel command line can also be provided by the dhcp server with the root-path option. See the section called “Network Boot”.
For a full reference of all kernel command line parameters, see dracut.cmdline(7).
To get a quick start for the suitable kernel command line on your system, use the --print-cmdline option:
# dracut --print-cmdline root=UUID=8b8b6f91-95c7-4da2-831b-171e12179081 rootflags=rw,relatime,discard,data=ordered rootfstype=ext4
This is the only option dracut really needs to boot from your root partition.
Because your root partition can live in various environments, there are a lot of
formats for the root= option. The most basic one is root=<path to device
node>:
root=/dev/sda2
Because device node names can change, dependent on the drive ordering, you are encouraged to use the filesystem identifier (UUID) or filesystem label (LABEL) to specify your root partition:
root=UUID=19e9dda3-5a38-484d-a9b0-fa6b067d0331
or
root=LABEL=myrootpartitionlabel
To see all UUIDs or LABELs on your system, do:
# ls -l /dev/disk/by-uuid
or
# ls -l /dev/disk/by-label
If your root partition is on the network see the section called “Network Boot”.
If you have to input passwords for encrypted disk volumes, you might want to set the keyboard layout and specify a display font.
A typical german kernel command line would contain:
rd.vconsole.font=eurlatgr rd.vconsole.keymap=de-latin1-nodeadkeys rd.locale.LANG=de_DE.UTF-8
Setting these options can override the setting stored on your system, if you use a modern init system, like systemd.
Sometimes it is required to prevent the automatic kernel module loading of a
specific kernel module. To do this, just add rd.driver.blacklist=<kernel
module name>, with <kernel module name> not containing the .ko
suffix, to the kernel command line. For example:
rd.driver.blacklist=mptsas rd.driver.blacklist=nouveau
The option can be specified multiple times on the kernel command line.
If you want to speed up the boot process, you can specify as much information for dracut on the kernel command as possible. For example, you can tell dracut, that you root partition is not on a LVM volume or not on a raid partition, or that it lives inside a specific crypto LUKS encrypted volume. By default, dracut searches everywhere. A typical dracut kernel command line for a plain primary or logical partition would contain:
rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0
This turns off every automatic assembly of LVM, MD raids, DM raids and crypto LUKS.
Of course, you could also omit the dracut modules in the initramfs creation process, but then you would lose the possibility to turn it on on demand.
To add your own files to the initramfs image, you have several possibilities.
The --include option let you specify a source path and a target path. For example
# dracut --include cmdline-preset /etc/cmdline.d/mycmdline.conf initramfs-cmdline-pre.img
will create an initramfs image, where the file cmdline-preset will be copied inside the initramfs to /etc/cmdline.d/mycmdline.conf. --include can only be specified once.
# mkdir -p rd.live.overlay/etc/cmdline.d
# mkdir -p rd.live.overlay/etc/conf.d
# echo "ip=dhcp" >> rd.live.overlay/etc/cmdline.d/mycmdline.conf
# echo export FOO=testtest >> rd.live.overlay/etc/conf.d/testvar.conf
# echo export BAR=testtest >> rd.live.overlay/etc/conf.d/testvar.conf
# tree rd.live.overlay/
rd.live.overlay/
`-- etc
|-- cmdline.d
| `-- mycmdline.conf
`-- conf.d
`-- testvar.conf
# dracut --include rd.live.overlay / initramfs-rd.live.overlay.imgThis will put the contents of the rd.live.overlay directory into the root of the initramfs image.
The --install option let you specify several files, which will get installed in the initramfs image at the same location, as they are present on initramfs creation time.
# dracut --install 'strace fsck.ext4 ssh' initramfs-dbg.img
This will create an initramfs with the strace, fsck.ext4 and ssh executables, together with the libraries needed to start those. The --install option can be specified multiple times.
If your root partition is on a network drive, you have to have the network dracut modules installed to create a network aware initramfs image.
If you specify ip=dhcp on the kernel command line, then dracut asks a dhcp server about the ip address for the machine. The dhcp server can also serve an additional root-path, which will set the root device for dracut. With this mechanism, you have static configuration on your client machine and a centralized boot configuration on your TFTP/DHCP server. If you can’t pass a kernel command line, then you can inject /etc/cmdline.d/mycmdline.conf, with a method described in the section called “Injecting custom Files”.
To reduce the size of the initramfs, you should create it with by omitting all dracut modules, which you know, you don’t need to boot the machine.
You can also specify the exact dracut and kernel modules to produce a very tiny initramfs image.
For example for a NFS image, you would do:
# dracut -m "nfs network base" initramfs-nfs-only.img
Then you would boot from this image with your target machine and reduce the size once more by creating it on the target machine with the --host-only option:
# dracut -m "nfs network base" --host-only initramfs-nfs-host-only.img
This will reduce the size of the initramfs image significantly.
If the boot process does not succeed, you have several options to debug the situation.
If you want to save that output, simply mount /boot by hand or insert an USB stick and mount that. Then you can store the output for later inspection.
In all cases, the following should be mentioned and attached to your bug report:
This section details information to include when experiencing problems on a system whose root device is located on a network attached volume (e.g. iSCSI, NFS or NBD). As well as the information from the section called “All bug reports”, include the following information:
Please include the output of
# /sbin/ifup <interfacename> # ip addr show
Successfully debugging dracut will require some form of console logging during the system boot. This section documents configuring a serial console connection to record boot messages.
Open the file /boot/grub2/grub.cfg for editing. Below the line 'timeout=5', add the following:
serial --unit=0 --speed=9600 terminal --timeout=5 serial console
Also in /boot/grub2/grub.cfg, add the following boot arguments to the 'kernel' line:
console=tty0 console=ttyS0,9600
When finished, the /boot/grub2/grub.cfg file should look similar to the example below.
default=0 timeout=5 serial --unit=0 --speed=9600 terminal --timeout=5 serial console title Fedora (2.6.29.5-191.fc11.x86_64) root (hd0,0) kernel /vmlinuz-2.6.29.5-191.fc11.x86_64 ro root=/dev/mapper/vg_uc1-lv_root console=tty0 console=ttyS0,9600 initrd /dracut-2.6.29.5-191.fc11.x86_64.img
Redirecting non-interactive output
You can redirect all non-interactive output to /dev/kmsg and the kernel will put it out on the console when it reaches the kernel buffer by doing
# exec >/dev/kmsg 2>&1 </dev/console
dracut offers a shell for interactive debugging in the event dracut fails to locate your root filesystem. To enable the shell:
Remove the boot arguments 'rhgb' and 'quiet'
A sample /boot/grub2/grub.cfg bootloader configuration file is listed below.
default=0 timeout=5 serial --unit=0 --speed=9600 terminal --timeout=5 serial console title Fedora (2.6.29.5-191.fc11.x86_64) root (hd0,0) kernel /vmlinuz-2.6.29.5-191.fc11.x86_64 ro root=/dev/mapper/vg_uc1-lv_root console=tty0 rd.shell initrd /dracut-2.6.29.5-191.fc11.x86_64.img
If system boot fails, you will be dropped into a shell as seen in the example below.
No root device found Dropping to debug shell. #
From the dracut debug shell, you can manually perform the task of locating and preparing your root volume for boot. The required steps will depend on how your root volume is configured. Common scenarios include:
The exact method for locating and preparing will vary. However, to continue with a successful boot, the objective is to locate your root volume and create a symlink /dev/root which points to the file system. For example, the following example demonstrates accessing and booting a root volume that is an encrypted LVM Logical volume.
Inspect your partitions using parted
# parted /dev/sda -s p Model: ATA HTS541060G9AT00 (scsi) Disk /dev/sda: 60.0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 10.8GB 107MB primary ext4 boot 2 10.8GB 55.6GB 44.7GB logical lvm
You recall that your root volume was a LVM logical volume. Scan and activate any logical volumes.
# lvm vgscan # lvm vgchange -ay
You should see any logical volumes now using the command blkid:
# blkid /dev/sda1: UUID="3de247f3-5de4-4a44-afc5-1fe179750cf7" TYPE="ext4" /dev/sda2: UUID="Ek4dQw-cOtq-5MJu-OGRF-xz5k-O2l8-wdDj0I" TYPE="LVM2_member" /dev/mapper/linux-root: UUID="def0269e-424b-4752-acf3-1077bf96ad2c" TYPE="crypto_LUKS" /dev/mapper/linux-home: UUID="c69127c1-f153-4ea2-b58e-4cbfa9257c5e" TYPE="ext4" /dev/mapper/linux-swap: UUID="47b4d329-975c-4c08-b218-f9c9bf3635f1" TYPE="swap"
From the output above, you recall that your root volume exists on an encrypted block device. Following the guidance disk encryption guidance from the Installation Guide, you unlock your encrypted root volume.
# UUID=$(cryptsetup luksUUID /dev/mapper/linux-root) # cryptsetup luksOpen /dev/mapper/linux-root luks-$UUID Enter passphrase for /dev/mapper/linux-root: Key slot 0 unlocked.
Next, make a symbolic link to the unlocked root volume
# ln -s /dev/mapper/luks-$UUID /dev/root
With the root volume available, you may continue booting the system by exiting the dracut shell
# exit
To debug the shutdown sequence on systemd systems, you can rd.break on pre-shutdown or shutdown.
To do this from an already booted system:
# mkdir -p /run/initramfs/etc/cmdline.d # echo "rd.debug rd.break=pre-shutdown rd.break=shutdown" > /run/initramfs/etc/cmdline.d/debug.conf # touch /run/initramfs/.need_shutdown
This will give you a dracut shell after the system pivot’ed back in the initramfs.
# dracut --kver 3.5.0-0.rc7.git1.2.fc18.x86_64
Add a space-separated list of dracut modules to the default set of modules. This parameter can be specified multiple times.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --add "module1 module2" ...
Force to add a space-separated list of dracut modules to the default set of modules, when -H is specified. This parameter can be specified multiple times.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --force-add "module1 module2" ...
Omit a space-separated list of dracut modules. This parameter can be specified multiple times.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --omit "module1 module2" ...
Specify a space-separated list of dracut modules to call when building the initramfs. Modules are located in /usr/lib/dracut/modules.d. This parameter can be specified multiple times. This option forces dracut to only include the specified dracut modules. In most cases the "--add" option is what you want to use.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --modules "module1 module2" ...
Specify a space-separated list of kernel modules to exclusively include in the initramfs. The kernel modules have to be specified without the ".ko" suffix. This parameter can be specified multiple times.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --drivers "kmodule1 kmodule2" ...
Specify a space-separated list of kernel modules to add to the initramfs. The kernel modules have to be specified without the ".ko" suffix. This parameter can be specified multiple times.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --add-drivers "kmodule1 kmodule2" ...
See add-drivers above. But in this case it is ensured that the drivers are tried to be loaded early via modprobe.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --force-drivers "kmodule1 kmodule2" ...
Specify a space-separated list of kernel modules not to add to the initramfs. The kernel modules have to be specified without the ".ko" suffix. This parameter can be specified multiple times.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --omit-drivers "kmodule1 kmodule2" ...
Specify a space-separated list of kernel filesystem modules to exclusively include in the generic initramfs. This parameter can be specified multiple times.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --filesystems "filesystem1 filesystem2" ...
Specify a space-separated list of directories to look for libraries to include in the generic initramfs. This parameter can be specified multiple times.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --libdirs "dir1 dir2" ...
Add a space-separated list of fsck tools, in addition to dracut.conf's specification; the installation is opportunistic (non-existing tools are ignored).
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --fscks "fsck.foo barfsck" ...
Specify configuration file to use.
Default: /etc/dracut.conf
Specify configuration directory to use.
Default: /etc/dracut.conf.d
Specify temporary directory to use.
Default: /var/tmp
Specify the sysroot directory to collect files from. This is useful to create the initramfs image from a cross-compiled sysroot directory. For the extra helper variables, see ENVIRONMENT below.
Default: empty
Logfile to use; overrides any setting from the configuration files.
Default: /var/log/dracut.log
Host-only mode: Install only what is needed for booting the local host instead of a generic host and generate host-specific configuration.
If chrooted to another root other than the real root device, use "--fstab" and provide a valid /etc/fstab.
Specify the host-only mode to use. <mode> could be one of "sloppy" or "strict". In "sloppy" host-only mode, extra drivers and modules will be installed, so minor hardware change won’t make the image unbootable (e.g. changed keyboard), and the image is still portable among similar hosts. With "strict" mode enabled, anything not necessary for booting the local host in its current state will not be included, and modules may do some extra job to save more space. Minor change of hardware or environment could make the image unbootable.
Default: sloppy
Install the space separated list of files into the initramfs.
If the list has multiple arguments, then you have to put these in quotes. For example:
# dracut --install "/bin/foo /sbin/bar" ...
Compress the generated initramfs using bzip2.
Make sure your kernel has bzip2 decompression support compiled in, otherwise you will not be able to boot. Equivalent to "--compress=bzip2 -9".
Compress the generated initramfs using lzma.
Make sure your kernel has lzma decompression support compiled in, otherwise you will not be able to boot. Equivalent to "--compress=lzma -9 -T0".
Compress the generated initramfs using xz.
Make sure your kernel has xz decompression support compiled in, otherwise you will not be able to boot. Equivalent to "--compress=xz --check=crc32 --lzma2=dict=1MiB -T0".
Compress the generated initramfs using lzop.
Make sure your kernel has lzo decompression support compiled in, otherwise you will not be able to boot. Equivalent to "--compress=lzop -9".
Compress the generated initramfs using lz4.
Make sure your kernel has lz4 decompression support compiled in, otherwise you will not be able to boot. Equivalent to "--compress=lz4 -l -9".
Compress the generated initramfs using Zstandard.
Make sure your kernel has zstd decompression support compiled in, otherwise you will not be able to boot. Equivalent to "--compress=zstd -15 -q -T0".
0 - suppress any messages
1 - only fatal errors
2 - all errors
3 - warnings
4 - info
5 - debug info (here starts lots of output)
6 - trace info (and even more)sets the ldconfig program path and options. Optional. Used for --sysroot.
Default: ldconfig
sets the ldd program path and options. Optional. Used for --sysroot.
Default: ldd
sets the initially tested binary for detecting library paths. Optional. Used for --sysroot. In the cross-compiled sysroot, the default value (/bin/sh) is unusable, as it is an absolute symlink and points outside the sysroot directory.
Default: /bin/sh
overrides path and options for executing dracut-install internally. Optional. Can be used to debug dracut-install while running the main dracut script.
Default: dracut-install
Example: DRACUT_INSTALL="valgrind dracut-install"
overrides for compression utilities to support using them from non-standard paths.
Default values are the default compression utility names to be found in PATH.
overrides the value of uname -m. Used for --sysroot.
Default: empty (the value of uname -m on the host system)
overrides PATH environment for dracut-install to look for binaries relative to --sysroot. In a cross-compiled environment (e.g. Yocto), PATH points to natively built binaries that are not in the host’s /bin, /usr/bin, etc. dracut-install still needs plain /bin and /usr/bin that are relative to the cross-compiled sysroot.
Default: PATH
overrides DRACUT_LOG_TARGET for dracut-install. It allows running dracut-install* to run with different log target that dracut** runs with.
Default: DRACUT_LOG_TARGET
overrides DRACUT_LOG_LEVEL for dracut-install. It allows running dracut-install* to run with different log level that dracut** runs with.
Default: DRACUT_LOG_LEVEL
The dracut command is part of the dracut package and is available from https://github.com/dracut-ng/dracut-ng
Harald Hoyer
Victor Lowther
Amadeusz Żołnowski
Hannes Reinecke
Daniel Molkentin
Will Woods
Philippe Seewer
Warren Togami
dracut.conf is loaded during the initialisation phase of dracut. Command line parameter will override any values set here.
*.conf files are read from /usr/lib/dracut/dracut.conf.d and /etc/dracut.conf.d. Files with the same name in /etc/dracut.conf.d will replace files in /usr/lib/dracut/dracut.conf.d. The files are then read in alphanumerical order and will override parameters set in /etc/dracut.conf. Each line specifies an attribute and a value. A # indicates the beginning of a comment; following characters, up to the end of the line are not interpreted.
dracut command line options will override any values set here.
Configuration files must have the extension .conf; other extensions are ignored.
If chrooted to another root other than the real root device, use --fstab and provide a valid /etc/fstab.
Logging levels:
0 - suppress any messages
1 - only fatal errors
2 - all errors
3 - warnings
4 - info
5 - debug info (here starts lots of output)
6 - trace info (and even more)Table of Contents
The root device used by the kernel is specified in the boot configuration file on the kernel command line, as always.
The traditional root=/dev/sda1 style device specification is allowed, but not encouraged. The root device should better be identified by LABEL or UUID. If a label is used, as in root=LABEL=<label_of_root> the initramfs will search all available devices for a filesystem with the appropriate label, and mount that device as the root filesystem. root=UUID=<uuidnumber> will mount the partition with that UUID as the root filesystem.
In the following all kernel command line parameters, which are processed by dracut, are described.
"rd.*" parameters mentioned without "=" are boolean parameters. They can be turned on/off by setting them to {0|1}. If the assignment with "=" is missing "=1" is implied. For example rd.info can be turned off with rd.info=0 or turned on with rd.info=1 or rd.info. The last value in the kernel command line is the value, which is honored.
specify the block device to use as the root filesystem.
Example.
root=/dev/sda1 root=/dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:1:0-part1 root=/dev/disk/by-label/Root root=LABEL=Root root=/dev/disk/by-uuid/3f5ad593-4546-4a94-a374-bcfb68aa11f7 root=UUID=3f5ad593-4546-4a94-a374-bcfb68aa11f7 root=PARTUUID=3f5ad593-4546-4a94-a374-bcfb68aa11f7
"auto" if not specified.
Example.
rootfstype=ext4
resume from a swap partition
Example.
resume=/dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:1:0-part1 resume=/dev/disk/by-uuid/3f5ad593-4546-4a94-a374-bcfb68aa11f7 resume=UUID=3f5ad593-4546-4a94-a374-bcfb68aa11f7
Mount all mountable devices and search for ISO pointed by the argument. When the ISO is found set it up as a loop device. Device containing this ISO image will stay mounted at /run/initramfs/isoscandev. Using iso-scan/filename with a Fedora/Red Hat/CentOS Live iso should just work by copying the original kernel cmdline parameters.
Example.
menuentry 'Live Fedora 20' --class fedora --class gnu-linux --class gnu --class os {
set isolabel=Fedora-Live-LXDE-x86_64-20-1
set isofile="/boot/iso/Fedora-Live-LXDE-x86_64-20-1.iso"
loopback loop $isofile
linux (loop)/isolinux/vmlinuz0 boot=isolinux iso-scan/filename=$isofile root=live:LABEL=$isolabel ro rd.live.image quiet rhgb
initrd (loop)/isolinux/initrd0.img
}
If you are dropped to an emergency shell, the file /run/initramfs/rdsosreport.txt is created, which can be saved to a (to be mounted by hand) partition (usually /boot) or a USB stick. Additional debugging info can be produced by adding rd.debug to the kernel command line. /run/initramfs/rdsosreport.txt contains all logs and the output of some tools. It should be attached to any report about dracut problems.
Print memory usage info at various points, set the verbose level from 0 to 5.
Higher level means more debugging output:
0 - no output
1 - partial /proc/meminfo
2 - /proc/meminfo
3 - /proc/meminfo + /proc/slabinfo
4 - /proc/meminfo + /proc/slabinfo + memstrack summary
NOTE: memstrack is a memory tracing tool that tracks the total memory
consumption, and peak memory consumption of each kernel modules
and userspace progress during the whole initramfs runtime, report
is generated and the end of initramsfs run.
5 - /proc/meminfo + /proc/slabinfo + memstrack (with top memory stacktrace)
NOTE: memstrack (with top memory stacktrace) will print top memory
allocation stack traces during the whole initramfs runtime.keyboard translation table loaded by loadkeys; taken from keymaps directory; will be written as KEYMAP to /etc/vconsole.conf in the initramfs.
Example.
rd.vconsole.keymap=de-latin1-nodeadkeys
console font; taken from consolefonts directory; will be written as FONT to /etc/vconsole.conf in the initramfs.
Example.
rd.vconsole.font=eurlatgr
taken from the environment; if no UNICODE is defined we set its value in basis of LANG value (whether it ends with ".utf8" (or similar) or not); will be written as LANG to /etc/locale.conf in the initramfs.
Example.
rd.locale.LANG=pl_PL.utf8
keysource:, see
rd.luks.key below.
NB: If systemd is included in the dracut initrd, dracut’s built in removable device keying support won’t work. systemd will prompt for a password from the console even if you’ve supplied rd.luks.key. You may be able to use standard systemd fstab(5) syntax to get the same effect. If you do need rd.luks.key to work, you will have to exclude the "systemd" dracut module and any modules that depend on it. See dracut.conf(5) and https://bugzilla.redhat.com/show_bug.cgi?id=905683 for more information.
<keypath> is the pathname of a key file, relative to the root of the filesystem on some device. It’s REQUIRED. When <keypath> ends with .gpg it’s considered to be key encrypted symmetrically with GPG. You will be prompted for the GPG password on boot. GPG support comes with the crypt-gpg module, which needs to be added explicitly.
<keydev> identifies the device on which the key file resides. It may be the kernel name of the device (should start with "/dev/"), a UUID (prefixed with "UUID=") or a label (prefix with "LABEL="). You don’t have to specify a full UUID. Just its beginning will suffice, even if its ambiguous. All matching devices will be probed. This parameter is recommended, but not required. If it’s not present, all block devices will be probed, which may significantly increase boot time.
If <luksdev> is given, the specified key will only be used for the specified LUKS device. Possible values are the same as for <keydev>. Unless you have several LUKS devices, you don’t have to specify this parameter. The simplest usage is:
Example.
rd.luks.key=/foo/bar.key
As you see, you can skip colons in such a case.
Your LUKS partition must match your key file.
dracut provides keys to cryptsetup with -d (an older alias for --key-file). This uses the entire binary content of the key file as part of the secret. If you pipe a password into cryptsetup without -d or --key-file, it will be treated as text user input, and only characters before the first newline will be used. Therefore, when you’re creating an encrypted partition for dracut to mount, and you pipe a key into cryptsetup luksFormat,you must use -d -.
Here is an example for a key encrypted with GPG (warning: --batch-mode will overwrite the device without asking for confirmation):
gpg --quiet --decrypt rootkey.gpg | \
cryptsetup --batch-mode --key-file - \
luksFormat /dev/sda47If you use unencrypted key files, just use the key file pathname instead of the standard input. For a random key with 256 bits of entropy, you might use:
head -32c /dev/urandom > rootkey.key
cryptsetup --batch-mode --key-file rootkey.key \
luksFormat /dev/sda47You can also use regular key files on an encrypted keydev.
Compared to using GPG encrypted keyfiles on an unencrypted device this provides the following advantages:
To use an encrypted keydev you must ensure that it becomes
available by using the keyword keysource, e.g.
rd.luks.uuid=keysource:aaaa
aaaa being the uuid of the encrypted keydev.
Example:
Lets assume you have three disks A, B and C with the uuids aaaa, bbbb and cccc. You want to unlock A and B using keyfile keyfile. The unlocked volumes be A', B' and C' with the uuids AAAA, BBBB and CCCC. keyfile is saved on C' as /keyfile.
One luks keyslot of each A, B and C is setup with a passphrase. Another luks keyslot of each A and B is setup with keyfile.
To boot this configuration you could use:
rd.luks.uuid=aaaa rd.luks.uuid=bbbb rd.luks.uuid=keysource:cccc rd.luks.key=/keyfile:UUID=CCCC
Dracut asks for the passphrase for C and uses the keyfile to unlock A and B. If getting the passphrase for C fails it falls back to asking for the passphrases for A and B.
If you want C' to stay unlocked, specify a luks name for
it, e.g. rd.luks.name=cccc=mykeys, otherwise it gets closed
when not needed anymore.
specify the device, where /boot is located.
Example.
boot=/dev/sda1 boot=/dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:1:0-part1 boot=UUID=<uuid> boot=LABEL=<label>
It is recommended to either bind an interface to a MAC with the ifname argument, or to use the systemd-udevd predictable network interface names.
Predictable network interface device names based on:
See: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Two character prefixes based on the type of interface:
Type of names:
All multi-function PCI devices will carry the [f<function>] number in the device name, including the function 0 device.
When using PCI geography, The PCI domain is only prepended when it is not 0.
For USB devices the full chain of port numbers of hubs is composed. If the name gets longer than the maximum number of 15 characters, the name is not exported. The usual USB configuration == 1 and interface == 0 values are suppressed.
The following options are supported by the network-legacy dracut module. Other network modules might support a slightly different set of options; refer to the documentation of the specific network module in use. For NetworkManager, see nm-initrd-generator(8).
This parameter can be specified multiple times.
explicit network configuration. If you want do define a IPv6 address, put it in brackets (e.g. [2001:DB8::1]). This parameter can be specified multiple times. <peer> is optional and is the address of the remote endpoint for pointopoint interfaces and it may be followed by a slash and a decimal number, encoding the network prefix length.
Assign network device name <interface> (i.e. "bootnet") to the NIC with MAC <MAC>.
Do not use the default kernel naming scheme for the interface name, as it can conflict with the kernel names. So, don’t use "eth[0-9]+" for the interface name. Better name it "bootnet" or "bluesocket".
Add a static route with route options, which are separated by a colon. IPv6 addresses have to be put in brackets.
Example.
rd.route=192.168.200.0/24:192.168.100.222:ens10
rd.route=192.168.200.0/24:192.168.100.222
rd.route=192.168.200.0/24::ens10
rd.route=[2001:DB8:3::/8]:[2001:DB8:2::1]:ens10
netroot=dhcp alone directs initrd to look at the DHCP root-path where NFS options can be specified.
Example.
root-path=<server-ip>:<root-dir>[,<nfs-options>]
root-path=nfs:<server-ip>:<root-dir>[,<nfs-options>]
root-path=nfs4:<server-ip>:<root-dir>[,<nfs-options>]
mount cifs share from <server-ip>:/<root-dir>, if no server-ip is given, use dhcp next_server. if server-ip is an IPv6 address it has to be put in brackets, e.g. [2001:DB8::1]. If a username or password are not specified as part of the root, then they must be passed on the command line through cifsuser/cifspass.
Passwords specified on the kernel command line are visible for all users via the file /proc/cmdline and via dmesg or can be sniffed on the network, when using DHCP with DHCP root-path.
Set the cifs password, if not specified as part of the root.
Passwords specified on the kernel command line are visible for all users via the file /proc/cmdline and via dmesg or can be sniffed on the network, when using DHCP with DHCP root-path.
protocol defaults to "6", LUN defaults to "0". If the "servername" field is provided by BOOTP or DHCP, then that field is used in conjunction with other associated fields to contact the boot server in the Boot stage. However, if the "servername" field is not provided, then the "targetname" field is then used in the Discovery Service stage in conjunction with other associated fields. See rfc4173.
Passwords specified on the kernel command line are visible for all users via the file /proc/cmdline and via dmesg or can be sniffed on the network, when using DHCP with DHCP root-path.
Example.
root=iscsi:192.168.50.1::::iqn.2009-06.dracut:target0
If servername is an IPv6 address, it has to be put in brackets:
Example.
root=iscsi:[2001:DB8::1]::::iqn.2009-06.dracut:target0
multiple netroot options allow setting up multiple iscsi disks:
Example.
root=UUID=12424547 netroot=iscsi:192.168.50.1::::iqn.2009-06.dracut:target0 netroot=iscsi:192.168.50.1::::iqn.2009-06.dracut:target1
If servername is an IPv6 address, it has to be put in brackets:
Example.
netroot=iscsi:[2001:DB8::1]::::iqn.2009-06.dracut:target0
Passwords specified on the kernel command line are visible for all users via the file /proc/cmdline and via dmesg or can be sniffed on the network, when using DHCP with DHCP root-path. You may want to use rd.iscsi.firmware.
manually specify all iscsistart parameter (see iscsistart --help)
Passwords specified on the kernel command line are visible for all users via the file /proc/cmdline and via dmesg or can be sniffed on the network, when using DHCP with DHCP root-path. You may want to use rd.iscsi.firmware.
<param> will be passed as "--param <param>" to iscsistart. This parameter can be specified multiple times.
Example.
"netroot=iscsi rd.iscsi.firmware=1 rd.iscsi.param=node.session.timeo.replacement_timeout=30"
will result in
iscsistart -b --param node.session.timeo.replacement_timeout=30
rd.iscsi.ibft rd.iscsi.ibft=1: Turn on iBFT autoconfiguration for the interfaces
rd.iscsi.mp rd.iscsi.mp=1: Configure all iBFT interfaces, not only used for booting (multipath)
rd.iscsi.waitnet=0: Turn off waiting for all interfaces to be up before trying to login to the iSCSI targets.
rd.iscsi.testroute=0: Turn off checking, if the route to the iSCSI target IP is possible before trying to login.
Try to connect to a FCoE SAN through the NIC specified by <interface> or <MAC> or EDD settings. The second argument specifies if DCB should be used. The optional third argument specifies whether fabric or VN2VN mode should be used. This parameter can be specified multiple times.
letters in the MAC-address must be lowercase!
Discover and connect to a NVMe-over-Fabric controller specified by <traddr> and the optionally <host_traddr> or <trsvcid>. The first argument specifies the transport to use; currently only rdma, fc, or tcp are supported. This parameter can be specified multiple times.
Examples.
rd.nvmf.discover=tcp,192.168.10.10,,4420 rd.nvmf.discover=fc,nn-0x201700a05634f5bf:pn-0x201900a05634f5bf,nn-0x200000109b579ef3:pn-0x100000109b579ef3
mount nbd share from <server>.
NOTE: If "exportname" instead of "port" is given the standard port is used. Newer versions of nbd are only supported with "exportname".
netroot=dhcp alone directs initrd to look at the DHCP root-path where NBD options can be specified. This syntax is only usable in cases where you are directly mounting the volume as the rootfs.
NOTE: If "exportname" instead of "port" is given the standard port is used. Newer versions of nbd are only supported with "exportname".
Both formats are supported by the virtiofs dracut module. See https://gitlab.com/virtio-fs/virtiofsd for more information.
Example.
root=virtiofs:host rw
same syntax as the kernel module parameter (s390 only). For more details on the syntax see the IBM book "Linux on IBM Z and IBM LinuxONE - Device Drivers, Features, and Commands" https://www.ibm.com/docs/en/linux-on-systems?topic=overview-device-drivers-features-commands. This parameter can be specified multiple times.
NOTE: This parameter is no longer handled by dracut itself but with the exact same syntax by https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/dracut/95zdev.
rd.zfcp can be specified multiple times on the kernel command line.
NOTE: This parameter is no longer handled by dracut itself but with the exact same syntax by https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/dracut/95zdev.
If NPIV is enabled and the allow_lun_scan parameter to the zfcp module is set to Y then the zfcp driver will be initiating a scan internally and the <WWPN> and <FCPLUN> parameters can be omitted.
NOTE: This parameter is no longer handled by dracut itself but with the exact same syntax by https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/dracut/95zdev.
Example.
rd.zfcp=0.0.4000,0x5005076300C213e9,0x5022000000000000 rd.zfcp=0.0.4000
Assign network device name <interface> (i.e. "bootnet") to the NIC corresponds to the subchannels. This is useful when dracut’s default "ifname=" doesn’t work due to device having a changing MAC address.
Example.
rd.znet=qeth,0.0.0600,0.0.0601,0.0.0602,layer2=1,portname=foo rd.znet=ctc,0.0.0600,0.0.0601,protocol=bar
Dracut offers multiple options for live booted images:
Note — There are 3 separate overlay types available:
Using one of these technologies, the system will provide a writable overlay for the base, read-only SquashFS root filesystem. These methods enable a relatively fast boot and lower RAM usage.
With the original Device-mapper snapshot overlay, users must be careful to avoid writing too many blocks to the snapshot device. Once the blocks of the snapshot overlay are exhausted, the whole root filesystem becomes read-only leading to application failures. The snapshot overlay device is marked Overflow, and a difficult recovery is required to repair and enlarge the overlay offline.
When rd.live.overlay= is not specified for persistent overlay storage, or the specified file is not found or writable, a Device-mapper snapshot based non-persistent or temporary overlay is automatically created as a sparse file in RAM of the initramfs. This file will only consume content space as required blocks are allocated. This snapshot based overlay defaults to an apparent size of 32 GiB in RAM, and can be adjusted with the rd.live.overlay.size= kernel command line option. This file is hidden (and appears deleted) when the boot process switches out of the initramfs to the main root filesystem but its loop device remains connected to the Device-mapper snapshot.
Even with large Device-mapper overlay files for write space, the available root filesystem capacity is limited by the total allocated size of the base root filesystem, which often provide only a small number of gigabytes of free space.
This shortage could be remedied by building the root filesystem with more allocated free space, or the OverlayFS based overlay mount method can be used.
When the rd.live.overlay.overlayfs option is specified or when
rd.live.overlay= points to an appropriate directory with a sister at
/../ovlwork, then an OverlayFS based overlay mount is employed. Such a
persistent OverlayFS overlay can extend the available root filesystem storage
up to the capacity of the LiveOS disk device.
For non-persistent OverlayFS overlays, the /run/overlayfs directory in the
/run tmpfs is used for temporary storage. This filesystem is typically sized
to one half of the RAM total in the system.
The command: mount -o remount,size=<nbytes> /run will resize this virtual
filesystem after booting.
The internal SquashFS structure is traditionally expected to be:
squashfs.img | SquashFS from LiveCD .iso
!(mount)
/LiveOS
|- rootfs.img | Usually a ext4 filesystem image to mount read-only
!(mount)
/bin | Base Live root filesystem
/boot |
/dev |
... |For OverlayFS mount overlays, the internal SquashFS structure may be a direct compression of the root filesystem:
squashfs.img | SquashFS from LiveCD .iso !(mount) /bin | Base Live root filesystem /boot | /dev | ... |
Dracut uses one of the overlay methods of live booting by default. No additional command line options are required other than root=live:<path to blockdevice> or root=live:<URL> to specify the location of your squashed root filesystem.
/run/initramfs/squashed.img by using the rd.live.ram=1 option.
When the live system was installed with the --skipcompress option of the livecd-iso-to-disk installation script for Live USB devices, the root filesystem image, rootfs.img, is expanded on installation and no SquashFS is involved during boot.
/run/initramfs/rootfs.img in the
/run tmpfs.
The system will retrieve a compressed filesystem image, extract it to
/run/initramfs/fsimg/rootfs.img, connect it to a loop device, create a
writable, linear Device-mapper target at /dev/mapper/live-rw, and mount that
as a writable volume at /. More RAM is required during boot but the live
filesystem is easier to manage if it becomes full. Users can make a filesystem
image of any size and that size will be maintained when the system boots. There
is no persistence of root filesystem changes between boots with this option.
The filesystem structure is expected to be:
rootfs.tgz | Compressed tarball containing filesystem image
!(unpack)
/rootfs.img | Filesystem image at /run/initramfs/fsimg/
!(mount)
/bin | Live filesystem
/boot |
/dev |
... |To use this boot option, ensure that rd.writable.fsimg=1 is in your kernel command line and add the root=live:<URL> to specify the location of your compressed filesystem image tarball or SquashFS image.
Enables writable filesystem support. The system will boot with a fully writable (but non-persistent) filesystem without snapshots (see notes above about available live boot options). You can use the rootflags option to set mount options for the live filesystem as well (see documentation about rootflags in the Standard section above). This implies that the whole image is copied to RAM before the boot continues.
There must be enough free RAM available to hold the complete image.
This method is very suitable for diskless boots.
Specify minimum free RAM in MB after copying a live disk image into memory. The default is 1024.
This parameter only applies together with the parameters rd.writable.fsimg or rd.live.ram.
Boots a live image retrieved from <url>. Requires the dracut livenet module. Valid handlers: http, https, ftp, torrent, tftp.
Examples.
root=live:http://example.com/liveboot.img root=live:ftp://ftp.example.com/liveboot.img root=live:torrent://example.com/liveboot.img.torrent
/LiveOS.
Manage the usage of a persistent overlay.
<pathspec> is a path within the <devspec> filesystem to either
/run/overlayfs for a OverlayFS
mount overlay). (A required sister directory /<pathspec>/../ovlwork is
automatically made.)
The above method shall be used to persist the changes made to the root filesystem specified within the root=live:<path to blockdevice> or root=live:<url> device.
The default pathspec, when :auto or
no :<pathspec> is given, is /<rd.live.dir>/overlay-<label>-<uuid>,
where <label> and <uuid> are the LABEL and UUID of the filesystem specified
by the root=live:<path|url> device.
If a persistent overlay is detected at the standard LiveOS path, and rd.live.overlay.overlayfs is not set to 1, the overlay type (either Device-mapper or OverlayFS) will be detected and it will be used.
Examples.
rd.live.overlay=/dev/sdb1:/persistent-overlay.img rd.live.overlay=UUID=99440c1f-8daa-41bf-b965-b7240a8996f4
This is used to boot in a read-only mode with a normally read-write persistent overlay. With this option,
/dev/mapper/live‑ro)
of the base root filesystem and the persistent overlay, or
rootfs.img images, the above over a read-only loop device, or
/run/overlayfs‑r as an additional read-only lower layer stacked over the base
root filesystem, and /run/overlayfs becomes the temporary, writable, upper
directory overlay, to complete the bootable root filesystem.
Enables the use of the OverlayFS kernel module, if available, to provide a
copy-on-write union directory for the root filesystem. OverlayFS overlays are
directories of the files that have changed on the read-only base (lower)
filesystem. The root filesystem is provided through a special overlay type
mount that merges at least two directories, designated the lower and the upper.
If an OverlayFS upper directory is not present on the boot device, a tmpfs
directory will be created at /run/overlayfs to provide temporary storage.
Persistent storage can be provided on vfat or msdos formatted devices by
supplying the OverlayFS upper directory within an embedded filesystem that
supports the creation of trusted.* extended attributes and provides a valid
d_type in readdir responses, such as with btrfs, ext4, f2fs, & xfs. On
non-vfat-formatted devices, a persistent OverlayFS overlay can extend the
available root filesystem storage up to the capacity of the LiveOS disk device.
The rd.live.overlay.readonly option, which allows a persistent overlayfs to be mounted read-only through a higher level transient overlay directory, has been implemented through the multiple lower layers feature of OverlayFS.
Update the dracut commandline with the values found in the dracut-cmdline.conf file on the given device. The values are merged into the existing commandline values and the udev events are regenerated.
Example.
rd.zipl=UUID=0fb28157-99e3-4395-adef-da3f7d44835a
Remove the devices listed in <device-ids> from the default cio_ignore kernel command-line settings. <device-ids> is a list of comma-separated CCW device ids. The default for this value is taken from the /boot/zipl/active_devices.txt file.
Example.
rd.cio_accept=0.0.0180,0.0.0800,0.0.0801,0.0.0802
Set the path name of the kernel master key.
Example.
masterkey=/etc/keys/kmk-trusted.blob
Set the type of the kernel master key.
Example.
masterkeytype=trusted
Set the path name of the EVM HMAC key.
Example.
evmkey=/etc/keys/evm-trusted.blob
Set the path name of the EVM X.509 certificate.
Example.
evmx509=/etc/keys/x509_evm.der
Set the path name of the eCryptfs key.
Example.
ecryptfskey=/etc/keys/ecryptfs-trusted.blob
Here is a list of options and their new replacement.
rd_NO_MULTIPATH: rd.multipath=0
Table of Contents
lsinitrd [OPTION…] [<image> [<filename> [<filename> […] ]]]
lsinitrd [OPTION…] -k <kernel version>
lsinitrd shows the contents of an initramfs image. if <image> is omitted, then lsinitrd determines the default location based on the local configuration or Linux distribution policy.
The lsinitrd command is part of the dracut package and is available from https://github.com/dracut-ng/dracut-ng
Table of Contents
dracut uses a modular system to build and extend the initramfs image. All modules are located in /usr/lib/dracut/modules.d or in <git-src>/modules.d. The most basic dracut module is 99base. In 99base the initial shell script init is defined, which gets run by the kernel after initramfs loading. Although you can replace init with your own version of 99base, this is not encouraged. Instead you should use, if possible, the hooks of dracut. All hooks, and the point of time in which they are executed, are described in the section called “Boot Process Stages”.
The main script, which creates the initramfs is dracut itself. It parses all arguments and sets up the directory, in which everything is installed. It then executes all check, install, installkernel scripts found in the modules, which are to be processed. After everything is installed, the install directory is archived and compressed to the final initramfs image. All helper functions used by check, install and installkernel are found in in the file dracut-functions. These shell functions are available to all module installer (install, installkernel) scripts, without the need to source dracut-functions.
A module can check the preconditions for install and installkernel with the check script. Also dependencies can be expressed with check. If a module passed check, install and installkernel will be called to install all of the necessary files for the module. To split between kernel and non-kernel parts of the installation, all kernel module related parts have to be in installkernel. All other files found in a module directory are module specific and mostly are hook scripts and udev rules.
dracut modules can insert custom script at various points, to control the boot process. These hooks are plain directories containing shell scripts ending with ".sh", which are sourced by init. Common used functions are in dracut-lib.sh, which can be sourced by any script.
The cmdline hook is a place to insert scripts to parse the kernel command line and prepare the later actions, like setting up udev rules and configuration files.
In this hook the most important environment variable is defined: root. The second one is rootok, which indicates, that a module claimed to be able to parse the root defined. So for example, root=iscsi:…. will be claimed by the iscsi dracut module, which then sets rootok.
This hook is executed right after the cmdline hook and a check if root and rootok were set. Here modules can take action with the final root, and before udev has been run.
In this hook, you can set udev environment variables with udevadm control --property=KEY=value or control the further execution of udev with udevadm.
udev is triggered by calling udevadm trigger, which sends add events for all devices and subsystems.
In the main loop of dracut loops until udev has settled and all scripts in initqueue/finished returned true. In this loop there are three hooks, where scripts can be inserted by calling /sbin/initqueue.
This hook gets executed every time a script is inserted here, regardless of the udev state.
This hook (initqueue/timeout) gets executed, when the main loop counter becomes half of the rd.retry counter.
This hook (initqueue/online) gets executed whenever a network interface comes online (that is, once it is up and configured by the configured network module).
Before the root device is mounted all scripts in the hook pre-mount are executed. In some cases (e.g. NFS) the real root device is already mounted, though.
This hook is called before cleanup hook, This is a good place for actions other than cleanups which need to be called before pivot.
This hook is the last hook and is called before init finally switches root to the real root device. This is a good place to clean up and kill processes not needed anymore.
Init (or systemd) kills all udev processes, cleans up the environment, sets up the arguments for the real init process and finally calls switch_root. switch_root removes the whole filesystem hierarchy of the initramfs, chroot()s to the real root device and calls /sbin/init with the specified arguments.
To ensure all files in the initramfs hierarchy can be removed, all processes still running from the initramfs should not have any open file descriptors left.
A simple example module is 90kernel-modules, which modprobes a kernel module after udev has settled and the basic device drivers have been loaded.
All module installation information is in the file module-setup.sh.
First we create a check() function, which just exits with 0 indicating that this module should be included by default.
check():
return 0
Then we create the install() function, which installs a cmdline hook with priority number 20 called parse-insmodpost.sh. It also installs the insmodpost.sh script in /sbin.
install():
inst_hook cmdline 20 "$moddir/parse-insmodpost.sh" inst_simple "$moddir/insmodpost.sh" /sbin/insmodpost.sh
The parse-instmodpost.sh parses the kernel command line for a argument rd.driver.post, blacklists the module from being autoloaded and installs the hook insmodpost.sh in the initqueue/settled.
parse-insmodpost.sh:
for p in $(getargs rd.driver.post=); do
echo "blacklist $p" >> /run/modprobe.d/initramfsblacklist.conf
_do_insmodpost=1
done
[ -n "$_do_insmodpost" ] && /sbin/initqueue --settled --unique --onetime /sbin/insmodpost.sh
unset _do_insmodpostinsmodpost.sh, which is called in the initqueue/settled hook will just modprobe the kernel modules specified in all rd.driver.post kernel command line parameters. It runs after udev has settled and is only called once (--onetime).
insmodpost.sh:
. /lib/dracut-lib.sh
for p in $(getargs rd.driver.post=); do
modprobe $p
donecheck() is called by dracut to evaluate the inclusion of a dracut module in the initramfs.
check() should return with:
The function depends() should echo all other dracut module names the module depends on.
This function should print the kernel command line options needed to boot the current machine setup. It should start with a space and should not print a newline.
The install() function is called to install everything non-kernel related. To install binaries, scripts, and other files, you can use the functions mentioned in [creation].
To address a file in the current module directory, use the variable "$moddir".
In installkernel() all kernel related files should be installed. You can use all of the functions mentioned in [creation] to install files.
installs multiple binaries and files. If executables are specified without a path, dracut will search the path PATH=/usr/sbin:/sbin:/usr/bin:/bin for the binary. If the option "-o" is given as the first parameter, a missing file does not lead to an error.
installs one file <src> either to the same place in the initramfs or to an optional <dst>. inst with more than two arguments is treated the same as inst_multiple, all arguments are treated as files to install and none as install destinations.
installs an executable/script <src> in the dracut hook <hookdir> with priority <prio>.
installs one or more udev rules. Non-existent udev rules are reported, but do not let dracut fail.
instmods should be used only in the installkernel() function.
instmods installs one or more kernel modules in the initramfs. <kernelmodule> can also be a whole subsystem, if prefixed with a "=", like "=drivers/net/team".
instmods will not install the kernel module, if $hostonly is set and the kernel module is not currently needed by any /sys/…/uevent MODALIAS. To install a kernel module regardless of the hostonly mode use the form:
hostonly='' instmods <kernelmodule>
Table of Contents
This flow chart illustrates the ordering of the services, if systemd is used in the dracut initramfs.
systemd-journal.socket
|
v
dracut-cmdline.service
|
v
dracut-pre-udev.service
|
v
systemd-udevd.service
|
v
local-fs-pre.target dracut-pre-trigger.service
| |
v v
(various mounts) (various swap systemd-udev-trigger.service
| devices...) | (various low-level (various low-level
| | | services: seed, API VFS mounts:
v v v tmpfiles, random mqueue, configfs,
local-fs.target swap.target dracut-initqueue.service sysctl, ...) debugfs, ...)
| | | | |
\_______________|____________________ | ___________________|____________________/
\|/
v
sysinit.target
|
_________________/|\___________________
/ | \
| | |
v | v
(various | rescue.service
sockets...) | |
| | v
v | rescue.target
sockets.target |
| |
\_________________ | emergency.service
\| |
v v
basic.target emergency.target
|
______________________/|
/ |
| v
| initrd-root-device.target
| |
| v
| dracut-pre-mount.service
| |
| v
| sysroot.mount
| |
| v
| initrd-root-fs.target
(custom initrd services) |
| v
| dracut-mount.service
| |
| v
| initrd-parse-etc.service
| |
| v
| (sysroot-usr.mount and
| various mounts marked
| with fstab option
| x-initrd.mount)
| |
| v
| initrd-fs.target
\______________________ |
\|
v
initrd.target
|
v
dracut-pre-pivot.service
|
v
initrd-cleanup.service
isolates to
initrd-switch-root.target
|
v
______________________/|
/ |
| initrd-udevadm-cleanup-db.service
| |
(custom initrd services) |
| |
\______________________ |
\|
v
initrd-switch-root.target
|
v
initrd-switch-root.service
|
v
switch-rootThis work is 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.