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

Example.

rootfstype=ext4

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

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
}

Example.

rd.vconsole.keymap=de-latin1-nodeadkeys

Example.

rd.vconsole.font=eurlatgr

Example.

rd.locale.LANG=pl_PL.utf8

<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/sda47

If 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/sda47

You 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.

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:

en

wl

ww

Type of names:

o<index>

s<slot>[f<function>][d<dev_id>]

x<MAC>

[P<domain>]p<bus>s<slot>[f<function>][d<dev_id>]

[P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]

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.

PCI ethernet card with firmware index "1"

PCI ethernet card in hotplug slot with firmware index number

PCI ethernet multi-function card with 2 ports

PCI wlan card

USB built-in 3G modem

USB Android phone

dhcp|on|any

single-dhcp

auto6

dhcp6

either6

link6

dhcp|on|any|dhcp6

auto6

link6

<macaddr>

<macaddr>

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

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>]

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

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

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

Examples.

rd.nvmf.discover=tcp,192.168.10.10,,4420
rd.nvmf.discover=fc,nn-0x201700a05634f5bf:pn-0x201900a05634f5bf,nn-0x200000109b579ef3:pn-0x100000109b579ef3

NOTE: If "exportname" instead of "port" is given the standard port is used. Newer versions of nbd are only supported with "exportname".

NOTE: If "exportname" instead of "port" is given the standard port is used. Newer versions of nbd are only supported with "exportname".

root=virtiofs:host rw

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.

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.

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

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

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.

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.

This parameter only applies together with the parameters rd.writable.fsimg or rd.live.ram.

Examples.

root=live:http://example.com/liveboot.img
root=live:ftp://ftp.example.com/liveboot.img
root=live:torrent://example.com/liveboot.img.torrent

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

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.

Example.

rd.zipl=UUID=0fb28157-99e3-4395-adef-da3f7d44835a

Example.

rd.cio_accept=0.0.0180,0.0.0800,0.0.0801,0.0.0802

Example.

masterkey=/etc/keys/kmk-trusted.blob

Example.

masterkeytype=trusted

Example.

evmkey=/etc/keys/evm-trusted.blob

Example.

evmx509=/etc/keys/x509_evm.der

Example.

ecryptfskey=/etc/keys/ecryptfs-trusted.blob