nm-initrd-generator

nm-initrd-generator — early boot NetworkManager configuration generator

Synopsis

nm-initrd-generator [OPTIONS...] -- [CMDLINE...]

Description

nm-initrd-generator scans the command line for options relevant to network configuration and creates configuration files for an early instance of NetworkManager run from the initial ramdisk during early boot.

Options

-c | --connections-dir path

Output connection directory.

-p | --persistent-connections-dir path

Persistent connection directory. If it exists, rd.neednet will not cause a default connection to be generated in absence of other options.

-i | --initrd-data-dir path

Output directory for initrd data (e.g. hostname).

-d | --sysfs-dir path

The sysfs mount point.

-r | --run-config-dir path

Output directory for config files.

-s | --stdout

Dump connections to standard output. Useful for debugging.

CMDLINE

The options that appear on the kernel command line. The following options are recognized:

ip
rd.route
bridge
bond
team
vlan
ib.pkey
bootdev
nameserver
net.ifnames
rd.peerdns
rd.iscsi.ibft
rd.nvmf.nonbft
rd.bootif
rd.neednet
rd.ethtool
rd.net.dns
rd.net.dns-backend
rd.net.dns-resolve-mode
rd.net.timeout.dhcp
rd.net.dhcp.client-id
rd.net.dhcp.retry
rd.net.dhcp.vendor-class
rd.net.dhcp.dscp
rd.net.timeout.carrier
rd.net.timeout.ip-required
rd.znet
rd.znet_ifname
BOOTIF

Please consult the dracut.cmdline(7) manual for the documentation of the precise format of the values supported. Note that the values accepted for the configuration method of ip differ from dracut's, see the section below.

Running NetworkManager in the initrd

nm-initrd-generator only writes configuration; it is a separate NetworkManager instance that applies it. NetworkManager ships the systemd units for that instance, so any systemd-based initramfs can use them, not only dracut(8). They are:

NetworkManager-config-initrd.service

Runs very early, before systemd-udevd.service. It clears any stale profiles from /run/NetworkManager/system-connections, runs nm-initrd-generator on the contents of /proc/cmdline, creates the flag file /run/NetworkManager/initrd/neednet if at least one connection profile exists, and then applies the hostname if one was given.

NetworkManager-initrd.service

Runs the NetworkManager daemon with the initrd configuration tag enabled. It is a Type=dbus unit and requires a running message bus. It is skipped unless the neednet flag file exists and at least one profile is present under /usr/lib, /run or /etc/NetworkManager/system-connections.

NetworkManager-wait-online-initrd.service

Blocks until startup is complete, using nm-online -s.

The units carry no [Install] section and cannot be enabled with systemctl enable. NetworkManager instead installs a systemd system generator, nm-initrd-generator.sh, which wires them into initrd.target.wants when SYSTEMD_IN_INITRD is 1, additionally linking NetworkManager-wait-online-initrd.service into network-online.target.wants, and masks them on the real root. It masks the host units inside the initrd for the same reason: NetworkManager.service and NetworkManager-initrd.service both claim the org.freedesktop.NetworkManager bus name, so only one of them may be active at a time. An initramfs that includes the generator script therefore does not need to create any .wants symlinks itself. The script is a bash script and uses arrays, so an image that provides only a minimal sh must include bash as well; systemd skips a generator it cannot execute without reporting an error, and the units then never run. Note that some distributions do not ship the generator or the initrd units, and rely on their own equivalents instead.

The generated profiles live in /run/NetworkManager/system-connections, which systemd carries over into the real root at switch-root. The NetworkManager instance on the real root reads the same directory through its keyfile plugin, so a connection configured in the initrd keeps its UUID and stays active. A profile named Wired Connection on a running system normally originates this way.

An initramfs other than dracut's has to supply the environment these units expect. All three assert /etc/initrd-release, so that file has to exist in the image. NetworkManager-initrd.service is Type=dbus and binds to dbus.service: a bus implementation, its configuration and NetworkManager's D-Bus policy file (org.freedesktop.NetworkManager.conf) must be present, and the bus must be reachable at the point the unit runs, and not only once a late target such as sockets.target has been reached. The image also needs the kernel module for the network interface, and, if an ip argument names an interface, whatever udev link configuration the running system uses to arrive at that name. An initramfs that omits it will present the kernel name instead, which such an ip argument then fails to match.

None of these units is ordered against the encryption stage. Where the root device is encrypted and the network exists in order to deliver its passphrase, that ordering has to be added, and an ordering dependency alone is not enough: systemd-cryptsetup@.service is generated with After=cryptsetup-pre.target and nothing pulls that target into the transaction, so a unit that is merely Before=cryptsetup-pre.target is ordered against a target that never runs and has no effect. Declare both Wants=cryptsetup-pre.target and Before=cryptsetup-pre.target, and make sure the target itself is present in the image; a dependency naming a unit the image does not contain is dropped without a diagnostic. Note also that NetworkManager-wait-online-initrd.service runs with NM_ONLINE_TIMEOUT set to 3600. Once it precedes the encryption stage, an interface that never comes up delays the passphrase prompt for that long, so a shorter timeout is usually wanted.

Differences from the network-legacy dracut module

nm-initrd-generator generates a set of connections that are then configured by the NetworkManager instance running in the initrd. There are some differences in behavior compared to the network-legacy dracut module:

  • The configuration method of the ip option is interpreted differently. network-legacy treats an empty or missing method as dhcp; NetworkManager treats it as auto, because the result also depends on whether addresses were given. The methods understood are none, dhcp, dhcp6, link6, auto and ibft, with off, fw, single-dhcp, auto6, on and any accepted as aliases. network-legacy accepts arbitrary comma-separated combinations of methods; of these NetworkManager gives only dhcp,dhcp6 a distinct meaning, mapping it to DHCPv4 with automatic IPv6. A method it does not recognize is not reported as an error: in the bare ip=METHOD form it silently becomes auto, and in the longer forms the field is parsed as part of the address specification instead, which usually yields no connection at all.

  • When an interface is configured with a static address and a gateway, the network-legacy module waits that the gateway responds to arping requests before proceeding, while NetworkManager doesn't.

  • network-legacy configures interfaces one by one in the order in which they are announced by udev. If multiple interfaces specify a hostname (from command line or from DHCP), the one from the last interface activated wins. With NetworkManager, hostnames from command line have higher precedence over ones from DHCP, and the last that appears in the command line wins.

  • NetworkManager supports the ib.pkey=PARENT.PKEY argument to set up an Infiniband partition on IPoIB parent device PARENT using the specified partition key PKEY. The partition key must be in hexadecimal notation without leading "0x", for example "ib.pkey=ib0.8004".

  • NetworkManager supports the rd.ethtool=INTERFACE:AUTONEG:SPEED kernel command line option to set up ethtool NIC configuration parameters AUTONEG and SPEED. The INTERFACE being configured must be specified, and the other parameters are optional and can be left blank. When SPEED is set, duplex mode is automatically set to 'full'. INTERFACE accepts string values, AUTONEG accepts boolean values (true and false / on or off / 0 or 1), and SPEED accepts positive integer values.

  • NetworkManager supports the rd.net.dns-backend=VALUE kernel command line option to configure the DNS processing mode. See the description of the "dns" key in the "main section" paragraph of NetworkManager.conf(5). For example: rd.net.dns-backend=systemd-resolved, rd.net.dns-backend=dnsconfd

  • NetworkManager supports the rd.net.dns=SERVER kernel command line option to configure a global (non interface-specific) DNS server. The option can be specified multiple time to add more than one server. Each server can be specified as a plain IP or as an URI according to the description in the "global-dns-domains sections" paragraph of NetworkManager.conf(5). For example: rd.net.dns=2001:db8::1, rd.net.dns=dns+tls://192.0.2.0, rd.net.dns=dns+tls://[2001:db8::2]:5353#example.org. In addition, it supports configuring the "resolve-mode" key in the global DNS configuration via the rd.net.dns-resolve-mode command line option.

  • NetworkManager supports the rd.net.dhcp.dscp={CS0|CS4|CS6} kernel command line option to set a specific DSCP (TOS) value in the IP header of DHCP messages.

  • NetworkManager supports the rd.net.dhcp.client-id=interface:client-id kernel command line option to set a specific DHCPv4 client identifier for the given interface. The client-id can be specified either as a sequence of bytes in hexadecimal format separated by dashes, or as the character '@' followed by a non-empty string. When using the second format, NetworkManager prepends a zero byte to the given string, according to section 9.14 of RFC 2132. See the "ipv4.dhcp-client-id" section of nm-settings-nmcli(5) for more details. Examples: rd.net.dhcp.client-id=eth0:01-52-54-00-45-87-42, rd.net.dhcp.client-id=enp1s0:@example.com.

  • NetworkManager supports the rd.net.timeout.ip-required=SECONDS kernel command line option to configure, in seconds, the minimum amount of time that NetworkManager waits for both the IPv4 and IPv6 configuration attempts to complete when using ip=dhcp,dhcp6. This corresponds to the ipv4.required-timeout and ipv6.required-timeout connection properties. It defaults to 20 seconds; a value of 0 disables the required wait, and the special value infinity makes NetworkManager wait indefinitely. For example: rd.net.timeout.ip-required=5.

Propagation to the real root

The profiles are written to /run/NetworkManager/system-connections and are tagged with the org.freedesktop.NetworkManager.origin user setting, whose value is nm-initrd-generator.

/run is carried over when the initrd switches to the real root, so those profiles are still there when the second NetworkManager instance starts. It reads them and keeps the interfaces configured as the initrd left them. This is deliberate: it is what allows a system whose root filesystem is on the network to switch root without interrupting connectivity.

On a system that boots from local storage the propagation is usually not wanted, because the persistent profiles in /etc/NetworkManager/system-connections are meant to take over. To suppress it, drop a file in /etc/NetworkManager/conf.d containing:

[device]
keep-configuration=no
allowed-connections=except:origin:nm-initrd-generator

keep-configuration=no stops NetworkManager from adopting the existing interface configuration, so it activates the most suitable persistent profile instead; allowed-connections then prevents the initrd profiles from being activated at all. Both keys are described in NetworkManager.conf(5). A [device] section without a match-device key applies to every device; add one only to restrict the setting to particular interfaces.

This stops the initrd profiles from being used, but does not remove them. They stay visible as inactive profiles in nmcli connection show until the next boot, since /run does not survive a reboot. To remove them earlier, delete them with nmcli connection delete.

Exit Status

nm-initrd-generator exits with status 0. It ignores unrecognized options and prints an error message if it encounters a malformed option.

See Also

dracut.cmdline(7), NetworkManager(8), NetworkManager.conf(5), nm-settings-nmcli(5).