Server installation creates conflicting dracut and netplan networking configuration

Ubuntu Version

Ubuntu 26.04 LTS

Desktop Environment (if applicable)

None (server/headless)

Problem Description

After doing a standard server installation as a virtual machine, the 10-netplan-eth0.network systemd-networkd configuration file clashes with the Dracut-generated zzzz-dracut-default.network file. This causes the VM to request a DHCP address twice, leading to various strange behaviors.

In the journal, you can see:

Sep 03 15:30:11 localhost.localdomain systemd[1]: Started systemd-networkd.service - Network Management.
Sep 03 15:30:12 localhost.localdomain systemd-networkd[359]: eth0: Configuring with /run/systemd/network/zzzz-dracut-default.network.
Sep 03 15:30:12 localhost.localdomain systemd-networkd[359]: eth0: Link UP
Sep 03 15:30:12 localhost.localdomain systemd-networkd[359]: eth0: Gained carrier
Sep 03 15:30:12 localhost.localdomain systemd-networkd[359]: eth0: DHCPv4 address 192.168.0.68/24, gateway 192.168.0.1 acquired from 192.168.0.1
Sep 03 15:30:12 localhost.localdomain systemd[1]: Stopping systemd-networkd.service - Network Management...
Sep 03 15:30:12 localhost.localdomain systemd[1]: systemd-networkd.service: Deactivated successfully.
Sep 03 15:30:12 localhost.localdomain systemd[1]: Stopped systemd-networkd.service - Network Management.
Sep 03 15:30:18 hubu2604a systemd[1]: Starting systemd-networkd.service - Network Management...
Sep 03 15:30:18 hubu2604a systemd-networkd[1379]: lo: Link UP
Sep 03 15:30:18 hubu2604a systemd-networkd[1379]: lo: Gained carrier
Sep 03 15:30:18 hubu2604a systemd-networkd[1379]: eth0: Link UP
Sep 03 15:30:18 hubu2604a systemd-networkd[1379]: eth0: Gained carrier
Sep 03 15:30:18 hubu2604a systemd-networkd[1379]: eth0: Gained IPv6LL
Sep 03 15:30:18 hubu2604a systemd[1]: Started systemd-networkd.service - Network Management.
Sep 03 15:30:18 hubu2604a systemd-networkd[1379]: eth0: Found matching .network file, based on potentially unpredictable interface name: /run/systemd/network/1>
Sep 03 15:30:18 hubu2604a systemd-networkd[1379]: eth0: Configuring with /run/systemd/network/10-netplan-eth0.network.
Sep 03 15:30:18 hubu2604a systemd-networkd[1379]: eth0: DHCPv4 address 192.168.0.67/24, gateway 192.168.0.1 acquired from 192.168.0.1

So first systemd-networkd processes zzzz-dracut-default.network, sends a DHCP request for eth0 and gets an IP address (192.168.0.68 in this case). This is presumably during the initramfs phase.

Next, during the regular bootup, systemd-networkd processes 10-netplan-eth0.network (which is generated by netplan from the subiquity-generated /etc/netplan/00-installer-config.yaml). It sends another DHCP request, apparently with a different client ID or other settings, and therefore gets a different IP address, 192.168.0.67 in this case.

This causes various problems: the first address gets registered in dynamic DNS, but the second one isn’t, so the machine is not reachable via its DNS name, only the last acquired IP address.

I think this is an unfortunate interaction between the installer (subiquity), dracut, and netplan, and I would classify this as some sort of bug. But where to report this? In the launchpad for subiquity, dracut or netplan? Or some other sort of general networking category?

A workaround is to disable the dracut-generated network configuration for the initramfs, which is not needed in my particular case. Then again, having access to a network while breaking into the initramfs can be very handy!

Relevant System Information

This is a VM on a Hyper-V host, but the particular hypervisor is probably not relevant, only that it offers a virtual ethernet interface.

The installation of ubuntu-26.04.1-live-server-amd64.iso was done while leaving all the defaults as they were, basically pressing ENTER until you have to fill in user name and password, and the installer reboots.

Error Messages / Logs

See above.

What I’ve Tried

One workaround is to remove the dracut-network package or disable the module, as per https://askubuntu.com/a/1567352.

Another workaround is to disable or delete the generated /etc/netplan/00-installer-config.yamlconfig.yaml, which will cause only the dracut-generated network configuration to apply.

In both cases, the end result is that the eth0 interface is only activated once, and only one DHCP request is done.

Netplan is likely just the victim here given it never puts any files into /etc/netplan, it only processes them to turn them into systemd-networkd or network-manager configurations 


It looks like dracut needs to learn to use netplan instead of bypassing it and directly talking to networkd so I’d file the bug against the dracut Ubuntu package (not upstream since this is an Ubuntu integration issue)

Hm, I wonder if this is a regression, as I can’t remember this occurring when I tested the Ubuntu 26.04 betas on the same hypervisor. But maybe I didn’t look hard enough


That said, I think maybe the installer should make sure the dracut network configuration is disabled when it generates its own 00-installer-config-yaml, since most users would probably expect the netplan configuration to take precedence.

And I guess most users might not even be aware that the initramfs is doing network configuration! As far as I understand, this is a quite recent feature?

Ah, I see there is already Bug #2163380 “Ubuntu 26.04 Server performs two DHCP transactions...” : Bugs : dracut package : Ubuntu , as a dracut package bug.

I think it might also make sense to file a bug in the subiquity package, and link to that dracut bug.

Well, initrds have done network configuration nearly as long as they exist for nfs root and such, but Ubuntu used initramfs-tools (actually originally developed in Ubuntu and only later adopted by debian) since day one and only recently (well, in 25.10) switched to dracut so integration issues are indeed possible :slight_smile:

FWIW, I created Bug #2166411 “Installer should disable dracut-network modules if...” : Bugs : subiquity for subiquity.

1 Like

Your VM is having an identity crisis on boot :))

The reason for the two different IPs is systemd-networkd’s DHCP DUID (RFC 4361).

Inside the dracut initramfs, there is no real machine-id yet, so it generates a temporary one. Once the real OS mounts, netplan runs with your permanent machine-id. Your router sees _two_totally_different_clients_ asking for an IP on the same wire and goes- “Sure, here’s another address!” :-))

Two ways out -

1- Make them agree on MAC -

Add “dhcp-identifier: mac” to your netplan yaml and run “sudo netplan apply”. Both will use the plain MAC address and your router will keep the same lease.

2- If you don’t boot over NFS/iSCSI, drop network from the initrd completely:

echo ‘omit_dracutmodules+=" network "‘ | sudo tee /etc/dracut.conf.d/no-net.conf

sudo dracut -f

That stops the chaos :))

2 Likes

Yes, that is more or less what was already described in the askubuntu article, and in the linked bug reports.

But still I think this problem should be solved in the installer, since it now delivers by default a system which has undesirable behavior: a system should perform only one DHCP request per network interface on boot.

1 Like

Spot on!

Subiquity already inspects the storage layout during install - if root is on a local NVMe or SSD and not iSCSI or NFS, the installer has zero reason to pull dracut-network into the target initramfs by default.

Filing Bug on Subiquity was definitely the right call :wink:

1 Like

I’m glad I finally found this as have been trying to set a static IP on a new Ubuntu 26.04 VM all night and couldn’t work out why nothing was working, when every server I have set up in the past on previous versions has just worked straight away with netplan

It doesn’t matter if you set a static IP using netplan or in the GUI, once you reboot it’s gone again and is back to DHCP. Even restarting networking is enough to pick up the correct config and change the IP but then I wanted to avoid having to run some sort of cron job just to fix my IP again.

The only solution I could find that worked for me was to mask the Dracult file:

sudo ln -s /dev/null /etc/systemd/network/zzzz-dracut-default.network

Then create a new static IP file in the same format:

sudo nano /etc/systemd/network/zzzzz-static.network

Then paste in the details you want:

[Match]

Name=eth0

[Network]

DHCP=no

LinkLocalAddressing=no

IPv6AcceptRA=no

Address=10.10.10.52/16

Address=fc00:ddb0:5201:490e:10:10:10:52/64

Gateway=10.10.1.1

Gateway=fc00:ddb0:5201:490e:10:10:1:1

DNS=10.10.10.1

DNS=10.10.10.3

DNS=fc00:ddb0:5201:490e:10:10:10:1

DNS=fc00:ddb0:5201:490e:10:10:10:3

Domains=robindigital.co.uk

Seems like quite an annoying bug and surprising it wasn’t picked up before release, or hasn’t been fixed since April, especially as the GUI stuff gets overwritten too on reboot.

Setting a static IP shouldn’t be this hard.

Robin

No need to mask networkd files in /etc.

Purge the dracut-network package and run sudo dracut -f instead.
(-f is required, otherwise /boot keeps the old initramfs with the embedded DHCP client)

Unless you boot root over iSCSI or NFS, initrd has no business touching ethernet.
Once purged, standard Netplan static IP works on reboot.

The solution I used is the following. Add a file /etc/dracut.conf.d/systemd-networkd.conf, containing:

omit_dracutmodules+=" dyn-netconf "

Then run:

dracut --regenerate-all --force

This simply disables dracut’s dynamic network configuration module.

Note that when I tried to follow the earlier advice in the AskUbuntu thread linked above, which uses omit_dracutmodules+=" systemd-networkd " instead, I would get a complaint when running dracut:

dracut[E]: Module 'dyn-netconf' depends on module 'systemd-networkd', which can't be installed

I would rather not get this complaint every time, so I disabled the dyn-netconf module instead.

I also did not like the “bigger hammer” approach of attempting to remove the dracut-network package altogether, since then apt wanted to remove the dracut package, and replace it with initramfs-tools:

# apt purge dracut-network
The following package was automatically installed and is no longer required:
  dracut-core
Use 'apt autoremove' to remove it.

Installing dependencies:
  initramfs-tools

REMOVING:
  dracut*  dracut-network*

Summary:
  Upgrading: 0, Installing: 1, Removing: 2, Not Upgrading: 0
  Download size: 8,506 B
  Freed space: 255 kB

As far as I understand, Ubuntu 26.04 defaults to dracut now for generating initramfs images, whereas older versions defaulted to initramfs-tools.

Does anybody know what an upgrade of Ubuntu 24.04 to 26.04 will do if a machine uses initramfs-tools? Does it automatically attempt to migrate to dracut, or does it leave the initramfs-tools installation alone?

Btw, it would be great if people running into this issue confirmed https://bugs.launchpad.net/subiquity/+bug/2166411, so maybe somebody from Canonical will take a look at it? :slight_smile:

I took a further look, and indeed it is as I suspected: Ubuntu 26.04 desktop installations will not see this issue, because dracut-network is not installed by default. Ubuntu 26.04 server installations do get dracut-network.

I.e. the ubuntu-server meta-package depends on cloud-initramfs-dyn-netconf, which in turn depends on dracut-network:

$ apt info ubuntu-server 2>/dev/null | sed -n '/^Depends/s/, /,\n/gp'
Depends: apport,
bcache-tools,
btrfs-progs,
cloud-initramfs-copymods,
cloud-initramfs-dyn-netconf,
curl,
fonts-ubuntu-console,
git,
gnupg,
htop,
lvm2,
lxd-installer,
mdadm,
motd-news-config,
multipath-tools,
overlayroot,
patch,
software-properties-common,
sos,
tmux,
update-notifier-common,
vim,
xfsprogs,
xxd

and:

$ apt info cloud-initramfs-dyn-netconf 2>/dev/null | sed -n '/^Depends/s/, /,\n/gp'
Depends: dracut (>= 110) | initramfs-tools,
dracut-network (>= 110) | initramfs-tools,
systemd | initramfs-tools

whereas ubuntu-desktop does not have such a dependency:

$ apt info ubuntu-desktop 2>/dev/null | sed -n '/^Depends/s/, /,\n/gp'
Depends: alsa-base,
alsa-utils,
anacron,
at-spi2-core,
bc,
ca-certificates,
dmz-cursor-theme,
fontconfig,
fonts-dejavu-core,
foomatic-db-compressed-ppds,
gdm3,
ghostscript,
gnome-control-center,
gnome-menus,
gnome-session-canberra,
gnome-settings-daemon,
gnome-shell,
gnome-shell-ubuntu-extensions,
gstreamer1.0-alsa,
gstreamer1.0-packagekit,
gstreamer1.0-plugins-base-apps,
inputattach,
iw,
language-selector-common,
language-selector-gnome,
libatk-adaptor,
libnotify-bin,
libsasl2-modules,
nautilus,
openprinting-ppds,
pipewire-pulse,
printer-driver-pnm2ppa,
rfkill,
software-properties-common,
spice-vdagent,
ubuntu-desktop-minimal,
ubuntu-drivers-common,
ubuntu-release-upgrader-gtk,
ubuntu-session,
ubuntu-settings,
unzip,
update-manager,
update-notifier,
wireplumber,
wpasupplicant,
xdg-terminal-exec,
xdg-user-dirs,
xdg-user-dirs-gtk,
xkb-data,
yelp,
zenity,
zip

If you attempt to remove dracut-network on an Ubuntu Server installation, it will cause the ubuntu-server meta-package to be removed too. Normally you don’t want this, since that meta-package is meant to be adjusted later to optionally pull in other dependencies.

This topic was automatically closed 18 hours after the last reply. New replies are no longer allowed.