Public bug reported: Package
dracut / dracut-network 110-11 on Ubuntu 26.04 LTS (Resolute) Summary On a freshly installed Ubuntu Server 26.04 system with a local LVM root filesystem, dracut starts systemd-networkd in the initramfs and obtains a DHCPv4 lease even though the kernel command line contains neither ip= nor rd.neednet=1 and the root filesystem does not require networking. During switch-root, this instance of systemd-networkd is stopped. The real-root instance is then started with the Netplan-generated configuration and performs a second DHCP transaction. The initramfs transaction uses a MAC-based DHCP Client Identifier, while the real-root transaction uses the systemd default RFC 4361 IAID/DUID Client Identifier. A standards-compliant DHCP server therefore treats the same physical interface as two logical clients and can assign two different IPv4 addresses during a single boot. Environment Ubuntu 26.04 LTS (Resolute Raccoon) Kernel: 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Architecture: x86_64 Hypervisor: Proxmox/KVM, VirtIO network adapter dracut 110-11 dracut-core 110-11 dracut-network 110-11 netplan.io 1.2-1ubuntu5 systemd 259.5-0ubuntu3.4 systemd-resolved 259.5-0ubuntu3.4 The same behaviour has been observed on multiple independently installed Ubuntu 26.04 VMs. Storage and kernel command line The root filesystem is local LVM/ext4: /dev/mapper/ubuntu--vg-ubuntu--lv ext4 rw,relatime Kernel command line: BOOT_IMAGE=/vmlinuz-7.0.0-29-generic root=/dev/mapper/ubuntu--vg-ubuntu --lv ro crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M There is no ip=, rd.neednet=1, netroot=, NFS root, iSCSI root, or network-bound disk unlocking configuration. Initramfs network configuration The dracut-network package installs: /usr/lib/dracut/modules.d/11systemd-networkd/dracut-default.network During boot it appears as: /run/systemd/network/zzzz-dracut-default.network Its contents are: [Match] Kind=!* Type=!loopback [Network] DHCP=yes [DHCPv4] ClientIdentifier=mac RequestOptions=17 [DHCPv6] RequestOptions=59 60 This matches the VirtIO interface and starts DHCP in the initramfs despite networking not being required to mount the local root filesystem. Real-root network configuration The system uses Netplan with DHCPv4. Without an explicit dhcp- identifier: mac, the generated systemd-networkd configuration uses the normal systemd RFC 4361 IAID/DUID client identity. Relevant generated configuration: [Match] PermanentMACAddress=<same-interface-MAC> Name=ens18 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [DHCP] RouteMetric=100 UseMTU=true UseDNS=false UseDomains=false Steps to reproduce Install Ubuntu Server 26.04 in a VM using the standard local LVM storage layout and a DHCP-configured VirtIO interface. Do not configure ip=, rd.neednet=1, a network root filesystem, or network-bound disk unlocking. Leave Netplan at its default DHCPv4 client identifier behaviour (do not set dhcp-identifier: mac). Optionally create a DHCP reservation for the interface MAC to make the effect easier to observe. Capture UDP ports 67 and 68 on the DHCP server while rebooting the VM. Inspect the boot journal: journalctl -b -u systemd-networkd -u systemd-networkd-wait-online --no- pager Actual result Two separate systemd-networkd processes configure the same interface during one boot. First, in initramfs: systemd-networkd[275]: ens18: Configuring with /run/systemd/network/zzzz-dracut-default.network. systemd-networkd[275]: ens18: DHCPv4 address 192.168.40.90/24, gateway 192.168.40.1 acquired from 192.168.40.1 systemd[1]: Stopping systemd-networkd.service - Network Management... systemd[1]: Stopped systemd-networkd.service - Network Management. Then, after switch-root: systemd[1]: Starting systemd-networkd.service - Network Management... systemd-networkd[812]: ens18: Configuring with /run/systemd/network/10-netplan-ens18.network. systemd-networkd[812]: ens18: DHCPv4 address 192.168.40.102/24, gateway 192.168.40.1 acquired from 192.168.40.1 The initramfs systemd-networkd-wait-online unit also reports that initrd networking is not required: systemd-networkd-wait-online.service - Wait for Network to be Online skipped, unmet condition check ConditionPathExists=/run/networkd/initrd/neednet Packet capture evidence The packet capture contains two complete DHCP DORA sequences approximately 5.68 seconds apart. Both have the same Ethernet source address and BOOTP chaddr, but different DHCP Option 61 values. Stage DHCP transaction ID Option 61 Offered/ACKed address initramfs/dracut 0x66fbda75 type 1, interface MAC (01:<MAC>) 192.168.40.90 (reserved address) real root/Netplan 0x26aa1f85 RFC 4361 IAID/DUID (ff:<IAID>:<DUID>) 192.168.40.102 (dynamic pool) The DHCP server is the same in both transactions, and the physical MAC/chaddr is unchanged. Only Option 61 changes. A control capture made after setting Netplan dhcp-identifier: mac still shows two complete DHCP transactions per boot, but both use 01:<MAC> and both receive the same reserved address. This confirms that matching the identifiers only mitigates the two-address symptom; it does not remove the unnecessary initramfs DHCP transaction. How the attached packet capture was obtained The capture was made on the LAN interface of the DHCP server/firewall, not inside the affected VM, so it records the DHCP packets as they appeared on the network. Capture configuration: Capture system: pfSense Capture interface: LAN (vtnet1) Address family: IPv4 Protocol/filter: UDP ports 67 and 68 Packet count: unlimited Packet length: unlimited/full packet Promiscuous mode: disabled Name lookup: disabled VLAN filter: untagged packets only Procedure: A static DHCP reservation was configured for the VM interface MAC as 192.168.40.90. Netplan was left at its default DHCP identifier behaviour; no dhcp- identifier: mac override was present. Packet capture was started on the pfSense LAN interface. The Ubuntu VM was rebooted once. Capture was stopped after the VM completed booting. The resulting PCAP was filtered to DHCP only by capturing UDP ports 67 and 68. The attached capture contains nine packets: one DHCPRELEASE from the previous lease during shutdown; one complete DISCOVER/OFFER/REQUEST/ACK exchange from initramfs; one complete DISCOVER/OFFER/REQUEST/ACK exchange from the real-root system. No application payloads, credentials, authentication traffic, DNS queries or unrelated user traffic are included. The file does contain private IPv4 addresses, interface MAC addresses and the VM DHCP DUID because these fields are necessary to demonstrate the defect. Expected result For a system with a local root filesystem and no kernel command-line or other configuration requesting initramfs networking, dracut should not start DHCP in initramfs. At minimum, if an early DHCP transaction is intentionally required, DHCP identity and lease state should be handed over consistently to the real- root network configuration so that one physical interface is not presented to the DHCP server as two different clients during a single boot. Impact Two complete DHCP transactions are performed on every boot. One interface can consume two DHCP leases and receive two different addresses during one boot. A MAC-based reservation may be used only during initramfs, then replaced by a dynamic address after switch-root. The host can be briefly reachable at one address and then continue booting with another address. Automation, DNS registration, monitoring and firewall policies can observe inconsistent addresses. Networking is unnecessarily activated in early userspace, increasing exposure to untrusted DHCP responses before the real-root network policy is active. The initramfs profile requests DHCPv4 Root Path option 17 and DHCPv6 boot-related options even though the root filesystem is local. I am reporting this primarily as a functional/integration bug with potential security implications, not as a confirmed security vulnerability. Workarounds tested or identified Setting the following in Netplan makes both stages use a MAC-based Client Identifier: dhcp-identifier: mac This prevents two different leases on the tested DHCP server, but the duplicate DHCP transaction remains. If initramfs networking is not required, omitting the dracut systemd- networkd module or removing dracut-network also appears to prevent the early transaction, but this should not be necessary for a standard Ubuntu Server installation with local root storage. Questions for maintainers Should dracut-network/the systemd-networkd dracut module be included by default for a standard local-root Ubuntu Server installation? Should zzzz-dracut-default.network be generated or activated when neither ip= nor rd.neednet=1 is present? If early DHCP is intentional, should the DHCP Client Identifier or lease be kept consistent across switch-root? Is the continued presence of /run/systemd/network/zzzz-dracut- default.network after boot expected with Ubuntu's dracut 110-11 package? Related information A similar Ubuntu 26.04 user report discusses the unexpected zzzz-dracut- default.network file and suggests omitting the module when initramfs networking is not needed: https://askubuntu.com/questions/1567304/ubuntu-26-04-dracut-network- configuration Upstream dracut release notes also mention a related change, systemd- networkd: ensure zzzz-dracut-default.network cleanup, but the early DHCP transaction and differing client identities remain observable with Ubuntu package version 110-11. ** Affects: dracut (Ubuntu) Importance: Undecided Status: New ** Tags: dhcp initramfs netplan resolute server systemd-networkd ** Attachment added: "DHCP-only packet capture taken on the pfSense LAN interface during one VM reboot. It contains the shutdown DHCPRELEASE followed by two complete DHCP DORA exchanges: initramfs uses a MAC-based Client Identifier and receives the reserved address 192.168.40.90; the real-root system uses an RFC 4361 IAID/DUID Client Identifier and receives 192.168.40.102 from the dynamic pool." https://bugs.launchpad.net/bugs/2163380/+attachment/5991660/+files/packetcapture-vtnet1-20260813100352.pcap -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2163380 Title: Ubuntu 26.04 Server performs two DHCP transactions with different client identifiers during one boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2163380/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
