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.