.\" Automatically generated by Pandoc 3.1.9
.\"
.TH "NETPLAN-GENERATE" "8" "" "" ""
.SH NAME
\f[CR]netplan-generate\f[R] - generate back-end configuration from
Netplan YAML files
.SH SYNOPSIS
\f[B]\f[CB]netplan\f[B]\f[R] [\f[I]--debug\f[R]] \f[B]generate\f[R]
\f[B]-h\f[R]|\f[B]--help\f[R]
.PP
\f[B]\f[CB]netplan\f[B]\f[R] [\f[I]--debug\f[R]] \f[B]generate\f[R]
[\f[I]--root-dir ROOT_DIR\f[R]] [\f[I]--mapping MAPPING\f[R]]
.SH DESCRIPTION
\f[B]\f[CB]netplan generate\f[B]\f[R] converts Netplan YAML into
configuration files understood by the back ends
(\f[B]\f[CB]systemd-networkd\f[B]\f[R](8) or
\f[B]\f[CB]NetworkManager\f[B]\f[R](8)).
It \f[I]does not\f[R] apply the generated configuration.
.PP
You will not normally need to run this directly as it is run by
\f[B]\f[CB]netplan apply\f[B]\f[R], \f[B]\f[CB]netplan try\f[B]\f[R], or
at boot.
.PP
Only if executed during the systemd \f[CR]initializing\f[R] phase (i.e.
\[dq]Early boot, before \f[CR]basic.target\f[R] is reached\[dq]), will
it attempt to start/apply the newly created service units.
**Requires feature: \f[CR]generate-just-in-time*\f[R]*
.PP
When called as a systemd.generator(7), all the parsing and validation
errors will be ignored by default.
If network definitions are skipped due to parsing errors, they might be
incomplete.
That means that the back end configuration emitted might not be fully
valid.
.PP
For details of the configuration file format, see
\f[B]\f[CB]netplan\f[B]\f[R](5).
.SH OPTIONS
.TP
\f[CR]-h\f[R], \f[CR]--help\f[R]
Print basic help.
.TP
\f[CR]--debug\f[R]
Print debugging output during the process.
.TP
\f[CR]--root-dir\f[R] \f[I]\f[CI]ROOT_DIR\f[I]\f[R]
Instead of looking in \f[CR]/{lib,etc,run}/netplan\f[R], look in
\f[CR]/ROOT_DIR/{lib,etc,run}/netplan\f[R].
.TP
\f[CR]--mapping\f[R] \f[I]\f[CI]MAPPING\f[I]\f[R]
Instead of generating output files, parse the configuration files and
print some internal information about the device specified in
\f[I]\f[CI]MAPPING\f[I]\f[R].
.SH HANDLING MULTIPLE FILES
There are 3 locations that \f[B]\f[CB]netplan generate\f[B]\f[R]
considers:
.IP \[bu] 2
\f[CR]/lib/netplan/*.yaml\f[R]
.IP \[bu] 2
\f[CR]/etc/netplan/*.yaml\f[R]
.IP \[bu] 2
\f[CR]/run/netplan/*.yaml\f[R]
.PP
If there are multiple files with exactly the same name, then only one
will be read.
A file in \f[CR]/run/netplan\f[R] will shadow (completely replace) a
file with the same name in \f[CR]/etc/netplan\f[R].
A file in \f[CR]/etc/netplan\f[R] will itself shadow a file in
\f[CR]/lib/netplan\f[R].
.PP
Or, in other words, \f[CR]/run/netplan\f[R] is top priority, then
\f[CR]/etc/netplan\f[R], with \f[CR]/lib/netplan\f[R] having the lowest
priority.
.PP
If there are files with different names, then they are considered in
lexicographical order - regardless of the directory they are in.
Later files add to or override earlier files.
For example, \f[CR]/run/netplan/10-xyz.yaml\f[R] would be updated by
\f[CR]/lib/netplan/20-abc.yaml\f[R].
.PP
If you have two files with the same key/setting, the following rules
apply:
.IP \[bu] 2
If the values are YAML boolean or scalar values (numbers and strings)
the old value is overwritten by the new value.
.IP \[bu] 2
If the values are sequences, the sequences are concatenated - the new
values are appended to the old list.
.IP \[bu] 2
If the values are mappings, Netplan will examine the elements of the
mappings in turn using these rules.
.SH SEE ALSO
\f[B]\f[CB]netplan\f[B]\f[R](5), \f[B]\f[CB]netplan-apply\f[B]\f[R](8),
\f[B]\f[CB]netplan-try\f[B]\f[R](8),
\f[B]\f[CB]systemd-networkd\f[B]\f[R](8),
\f[B]\f[CB]NetworkManager\f[B]\f[R](8)
.SH AUTHORS
Daniel Axtens (\c
.MT daniel.axtens@canonical.com
.ME \c
).