nm-initrd-generatornm-initrd-generator — early boot NetworkManager configuration generator |
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.
|
Output connection directory. |
|||||||||||||||||||||||||||||
|
Persistent connection directory. If it exists, rd.neednet will not cause a default connection to be generated in absence of other options. |
|||||||||||||||||||||||||||||
|
Output directory for initrd data (e.g. hostname). |
|||||||||||||||||||||||||||||
|
The sysfs mount point. |
|||||||||||||||||||||||||||||
|
Output directory for config files. |
|||||||||||||||||||||||||||||
|
Dump connections to standard output. Useful for debugging. |
|||||||||||||||||||||||||||||
|
The options that appear on the kernel command line. The following options are recognized:
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
|
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:
|
Runs very early, before
|
|
Runs the NetworkManager daemon with the
|
|
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.
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.
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.