Generate Netplan Backend Files Without Applying Network Changes

You will use netplan generate to turn Netplan YAML into backend configuration, inspect what it produced, and avoid mistaking generation for applying a live network change. Allow about fifteen minutes. You need a Linux host with netplan.io installed and either an existing configuration to inspect or a disposable staging root for a test.

This guide follows netplan.io 1.1.2-8ubuntu1~24.04.3, installed on the machine used for these examples. Netplan releases and the selected backend can change the exact generated filenames and content, so use the installed command's output as the final authority.

1. Check the installed command

First confirm the binary and package version. These are ordinary, read-only commands and do not require elevated privileges:

$ command -v netplan
/usr/sbin/netplan
$ netplan --version
netplan.io 1.1.2-8ubuntu1~24.04.3
$ netplan generate --help
usage: /usr/sbin/netplan generate [-h] [--debug] [--root-dir ROOT_DIR]
                                  [--mapping MAPPING]

The command is normally run indirectly by netplan apply, netplan try or boot. Running it directly is useful when you want to separate parsing and file generation from the later operation that changes running networking.

2. Know which YAML is being merged

Netplan considers YAML files in /lib/netplan, /etc/netplan and /run/netplan. A same-named file in a higher-priority directory replaces the lower-priority file completely: /run wins over /etc, and /etc wins over /lib.

Different filenames are processed in lexicographical order, across all three directories. A later file can replace scalar values, append to sequences, and merge mappings. This is why a small file in /run/netplan can make an apparently correct file in /etc/netplan irrelevant, while a differently named file can still add settings to it.

Inspect the inputs before generating. Reading the directories is normally unprivileged, although permissions on a particular file may require an administrator:

$ find /lib/netplan /etc/netplan /run/netplan \
    -maxdepth 1 -type f -name '*.yaml' -print 2>/dev/null | sort
$ sudo find /lib/netplan /etc/netplan /run/netplan \
    -maxdepth 1 -type f -name '*.yaml' -print 2>/dev/null | sort

Use the second form only if the first cannot read a directory. Do not assume that a filename such as 99-local.yaml is a complete override: same-name shadowing and different-name merging follow separate rules.

3. Generate the live host's backend files

On a host whose Netplan files and permissions are ready, run:

$ sudo netplan generate
$ printf 'exit status: %s\n' "$?"
exit status: 0

Successful generation normally prints no report. A non-zero exit status means that parsing or validation failed; read the diagnostic, correct the YAML, and run the command again. Add --debug when you need more detail:

$ sudo netplan --debug generate

The generated files belong to the selected renderer, usually systemd-networkd or NetworkManager. Inspect the relevant generated locations after a successful run rather than guessing their contents:

$ sudo find /run/systemd/network /run/NetworkManager \
    -maxdepth 2 -type f -print 2>/dev/null | sort

This is an inspection step. netplan generate does not apply the result. Applying it is a separate, service-affecting action such as sudo netplan apply; it is intentionally outside this workflow.

4. Test in a disposable root first

For a safe review, point --root-dir at a disposable directory. Netplan then searches that root's lib/netplan, etc/netplan and run/netplan paths instead of the host paths. Create the YAML there with your normal editor or provisioning tool, keeping the top-level structure explicit:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true

Assume the file is /tmp/netplan-review/etc/netplan/01-example.yaml. Generate into that root as an ordinary user:

$ ROOT_DIR=/tmp/netplan-review
$ netplan --debug generate --root-dir "$ROOT_DIR"
$ find "$ROOT_DIR" -type f -print | sort

The last command shows which backend files were emitted. Their exact names depend on the renderer and interface definition. If the staging directory is not disposable, stop and inspect it before replacing anything. To undo this test, remove only the explicitly created /tmp/netplan-review directory after checking that it contains no unrelated files.

5. Inspect one device mapping when the output is confusing

--mapping parses the configuration and prints internal information for one device, rather than generating output files. Pass the Netplan device ID, not necessarily the operating system interface name:

$ sudo netplan generate --mapping ens3

Use the exact ID from the YAML. This command is a diagnostic aid; it does not repair a misspelled ID, and it is not a substitute for checking the merged input files. A device can also be selected by a name or matching rule in YAML, so compare the mapping result with the interface definition before drawing conclusions.

6. Recover from a failed or unwanted generation

If generation fails, it should not be treated as a successful network change. Save the complete error, check YAML indentation and types, and review all three input directories for shadowing or unexpected fragments. Re-run with --debug after each correction.

If you generated files from an unwanted YAML change but have not applied them, restore the YAML from your configuration-management system or from a backup, then run sudo netplan generate again. Do not delete generated files by hand as a first response: the next generation should recreate the consistent set for the active renderer. If you already ran netplan apply, use the documented rollback procedure for that change or restore the previous YAML and apply it deliberately; generation alone has no live-network undo operation.