Add ID_NET_NAME_INCLUDE_DOMAIN property support to systemd

[Robert Malz]

[Impact]

* This SRU back ports support for the new udev property ID_NET_NAME_INCLUDE_DOMAIN, allowing per-device control over domain inclusion in interface name. This change provides hardware enablement for Microsoft Azure Network Adapter (MANA) devices.

* In current Ubuntu LTS releases, systemd-udevd always includes the PCI domain in network interface names whenever the PCI domain index is greater than 0. This results in interface names such as:
With domain: enP2p0s0
Without domain: enp0s0

* There is no mechanism in Jammy/Noble/Questing to suppress the P<domain> segment.

* On Microsoft Azure, MANA devices commonly appear under non-zero PCI domains. However, Azure platform expectations and tooling assume interface names do not include the PCI domain segment. As a result, MANA interfaces currently receive unstable or unexpected names on Ubuntu LTS.

* As part of this change corresponding hwdb entry is added for MANA devices (PCI Vendor 0x1414, Device 0x00ba) which explicitly sets:
ID_NET_NAME_INCLUDE_DOMAIN=0

* This SRU consists of four components:
  - Core Support (net_id), upstream 19491cc:
Add recognition of ID_NET_NAME_INCLUDE_DOMAIN. If set to 0, the P<domain> segment is omitted even when domain > 0.

  - MANA Enablement (hwdb), upstream 9311c28:
Add a new hwdb entry matching the MANA PCI ID to set ID_NET_NAME_INCLUDE_DOMAIN=0.

  - udev/rules.d ordering fix, upstream a7deadd:
Ensure hwdb properties are imported before the net_id builtin runs, so the new property is honored.

- jammy-only helper, upstream 15345fc:
Backport device_get_property_bool(), which helps out jammy backport.

* Upstream patches which are back ported as part of this SRU are already available in Resolute and partially in Questing

[Test Plan]
Test 1: MANA enablement on Azure
Provision an Ubuntu Jammy or Noble VM with MANA support (e.g., Standard_D*v5).
Verify the MANA NIC is assigned a non-zero PCI domain.
Install the updated systemd package and reboot.
Run:
udevadm info /sys/class/net/<mana-interface>

Verify:
ID_NET_NAME_INCLUDE_DOMAIN=0 is present.

Verify:
The interface name does not include the domain segment.
Example expected transformation:
Before: enP2p0s0
After: enp0s0
Confirm normal network connectivity after rename.

Test 2: Mock virtio_net device on PCI domain > 0
Goal of this test is to mock virtio_net device on PCI domain 1 and verify if ID_NET_NAME_PATH is set accordingly.
For this test umockdev can be used to modify PCI domain on already existing device.
1. Add virtio_net to hwdb
sudo nano /usr/lib/udev/hwdb.d/20-net-ifname.hwdb
# Disable inclusion of PCI domain in interface names on Azure MANA
pci:v00001414d000000BA*
 ID_NET_NAME_INCLUDE_DOMAIN=0

pci:v00001AF4d00001041*
 ID_NET_NAME_INCLUDE_DOMAIN=0

2. Update hwdb
sudo systemd-hwdb update

3. Check current settings:
systemd-hwdb query "pci:v00001AF4d00001041*"
ID_VENDOR_FROM_DATABASE=Red Hat, Inc.
ID_MODEL_FROM_DATABASE=Virtio 1.0 network device
ID_NET_NAME_INCLUDE_DOMAIN=0

4. Mock virtio device on PCI domain 1
umockdev-run --device domain1.umockdev -- bash

5. test net_id and check ID_NET_NAME_PATH
udevadm test-builtin net_id /sys/devices/pci0001:00/0001:00:02.0/0001:01:00.0/virtio1/net/enp1s0/
expected output:
ID_NET_NAME_PATH=enp1s0

[Where Problems Could Occur]
1. Interface renaming due to overly broad hwdb matching
If the hwdb entry incorrectly matches non-MANA devices, those devices could receive ID_NET_NAME_INCLUDE_DOMAIN=0 and lose their domain segment, causing interface renames on upgrade.

2. Rule ordering changes
Commit a7deadd ensures hwdb is imported before running the net_id builtin.
Any custom site rules relying on the previous order may behave differently, although upstream considers the new ordering correct.

3. Jammy Backport Risk
Jammy carries the most technical risk because it predates all upstream changes related to device_get_property_bool(), the ordering fix, and the domain-inclusion feature. Much of the functionality had to be manually adapted to Jammy older sd-device, udev, and net_id codebases, as the upstream patches do not apply cleanly.
This manual backporting increases the chance of subtle issues in property parsing, fallback logic, boolean evaluation, and overall consistency. Any such error could cause system-wide misinterpretation of udev properties, not just for network devices. This is the most significant risk area of the SRU.

[Other Info]
* Backport Strategy
  - Noble:
Core net_id support + MANA hwdb entry + ordering fix.
  - Jammy:
Everything required for Noble plus the helper function device_get_property_bool().
  - Questing:
Only requires the core support patch (19491cc), as the other components are already present.

* domain1.umockdev file used in Test2 added as attachment

* noble systemd with patches applied is available in ppa: https://launchpad.net/~rmalz/+archive/ubuntu/sf00420640-domain

* Upstream Commits Included
https://github.com/systemd/systemd/commit/19491cc90f52704c32f129aa804f43045151c873
https://github.com/systemd/systemd/commit/9311c28b3407fbad69d0b747129b03ce1c7a6309
https://github.com/systemd/systemd/commit/a7deadd763427fcff67b6697557dfbd0c91647ec
https://github.com/systemd/systemd/commit/15345fc67739b8b62bcde55521a882d826faf801

[Robert Malz (rmalz)]

umockdev dummy file

[Robert Malz (rmalz)]

questing - https://code.launchpad.net/~rmalz/ubuntu/+source/systemd/+git/systemd/+merge/497019
noble - https://code.launchpad.net/~rmalz/ubuntu/+source/systemd/+git/systemd/+merge/497020
jammy - https://code.launchpad.net/~rmalz/ubuntu/+source/systemd/+git/systemd/+merge/497021

[Robert Malz (rmalz)]

Jammy/Noble verified based on Test 2, package available in https://launchpad.net/~rmalz/+archive/ubuntu/sf00420640-domain

[Timo Aaltonen (tjaalton)]

Hello Robert, or anyone else affected,

Accepted systemd into questing-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/257.9-0ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-questing to verification-done-questing. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-questing. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Robert Malz (rmalz)]

Verified on 25.10 systemd* 257.9-0ubuntu2.1
Tested (according to Test Plan -> Test 2):
- Adding ID_NET_NAME_INCLUDE_DOMAIN to 20-net-ifname.hwdb
 sudo systemd-hwdb update
rmalz@rmalz:~$ systemd-hwdb query "pci:v00001AF4d00001041*"
ID_VENDOR_FROM_DATABASE=Red Hat, Inc.
ID_MODEL_FROM_DATABASE=Virtio 1.0 network device
ID_NET_NAME_INCLUDE_DOMAIN=0

- udevadm test-builtin net_id with umockdev
rmalz@rmalz:~$ umockdev-run --device domain1.umockdev -- bash
rmalz@rmalz:~$ udevadm test-builtin net_id /sys/devices/pci0001:00/0001:00:02.0/0001:01:00.0/virtio1/net/enp1s0/
ID_NET_NAME_PATH=enp1s0
As expected

- extraa, udevadm test-builtin net_id with umockdev but with umockdev file without ID_NET_NAME_INCLUDE_DOMAIN=0
rmalz@rmalz:~$ umockdev-run --device domain1_dont_ignore.umockdev -- bash
rmalz@rmalz:~$ udevadm test-builtin net_id /sys/devices/pci0001:00/0001:00:02.0/0001:01:00.0/virtio1/net/enp1s0/
ID_NET_NAME_PATH=enP1p1s0
As expected

- extra, udevadm test-builtin net_id with umockdev file with ID_NET_NAME_INCLUDE_DOMAIN=1
rmalz@rmalz:~$ umockdev-run --device domain1_ignore_true.umockdev -- bash
rmalz@rmalz:~$ udevadm test-builtin net_id /sys/devices/pci0001:00/0001:00:02.0/0001:01:00.0/virtio1/net/enp1s0/
ID_NET_NAME_PATH=enP1p1s0
As expected

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted systemd (257.9-0ubuntu2.1) for questing have finished running.
The following regressions have been reported in tests triggered by the package:

at-spi2-core/2.57.1-1 (armhf)
cron/3.0pl1-196ubuntu2 (armhf)
cups/2.4.12-0ubuntu3.5 (armhf)
dbus/1.16.2-2ubuntu2 (armhf)
debci/3.12 (armhf)
debos/1.1.5-1 (amd64)
debvm/0.4.5 (s390x)
djbdns/1:1.05-22ubuntu1 (s390x)
dpdk/24.11.3-1 (ppc64el)
fetchmail/6.5.4-0ubuntu2 (armhf)
freedom-maker/0.34 (armhf)
fwupd/2.0.16-1 (armhf)
gnome-remote-desktop/49.0-0ubuntu1.1 (ppc64el, s390x)
inetutils/2:2.6-1ubuntu3 (armhf)
initramfs-tools/0.150ubuntu3.1 (arm64, s390x)
linux-realtime/6.17.0-1004.5 (amd64)
mariadb/1:11.8.3-1build1 (armhf)
mediawiki/1:1.43.3+dfsg-1 (s390x)
mutter/49.0-2ubuntu5.3 (armhf, ppc64el)
network-manager/1.52.0-1ubuntu3.1 (amd64, arm64, ppc64el)
postgresql-17/17.7-0ubuntu0.25.10.1 (armhf)
python-sdbus/0.14.0-1 (s390x)
slm/1.32-3 (i386)
tang/15-2ubuntu1 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/questing/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Andreas Hasenack (ahasenack)]

> With domain: enP2p0s0
> Without domain: enp0s0

If someone has tweaked their configuration to deal with the presence of P2 in the interface name, won't this SRU break their networking? Or is this a case where the presence of the domain component is already breaking the system, and there is no workaround people could have applied?

[Robert Malz (rmalz)]

Hey Andreas, the logic which changes interface name is only applied if ID_NET_NAME_INCLUDE_DOMAIN property is set on the device and currently (latest upstream) there is only a single device which sets this property and it's v00001414d000000BA (Azure Mana).

In other words whatever end user did to tweak interface naming, unless ID_NET_NAME_INCLUDE_DOMAIN is set in hwdb, will not be impacted by this change.

[Andreas Hasenack (ahasenack)]

My concern is breaking MANA systems who might have applied some sort of workaround already to cope with the extra domain component in the interface name. Could this update, which removes that extra component, cause breakages on such systems? This touching the network area, it could be a big deal if updated systems are left unreachable.

[Andreas Hasenack (ahasenack)]

What would happen to a system that had this netplan config, and was then updated to the packages provided by this SRU?
```
network:
  version: 2
  ethernets:
    enP2p0s0:
      dhcp4: true
```

Note the P2 component in the interface name, which would be gone after the update.

[Nick Rosbrook (enr0n)]

Explicitly blocking until we have feedback, since this update otherwise looks ready to release.

[Chris Patterson (cjp256)]

WRT

```
network:
  version: 2
  ethernets:
    enP2p0s0:
      dhcp4: true
```

Today, MANA devices should not be directly configured as they are bound to the Hyper-V nic (e.g. "eth0" would be configured in this example of enP2p0s0 as its master interface).

I think the concern here is that we want to get this change in (if possible) before the next generation of MANA which will be directly configurable as the bonded hyper-v nic will no longer be surfaced.

I cannot say there's zero risk of a customer using some configuration that uses the name of MANA VF but no use case comes to mind for me.

[Andreas Hasenack (ahasenack)]

That sounds OK then. +1 from me for release on this aspect (there is still an autopkgtest failure in qemu that needs sorting out, though).

[Nick Rosbrook (enr0n)]

Test cleared up on a retry, so this can be released next week.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 257.9-0ubuntu2.1

---------------
systemd (257.9-0ubuntu2.1) questing; urgency=medium

  * net_id: depending on new udev prop, include/exclude PCI domain from netif names
    (LP: #2134334)

 -- Robert Malz <email address hidden> Mon, 08 Dec 2025 09:30:21 -0500

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.