** Merge proposal linked:
   
https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/+git/systemd/+merge/429491

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1945225

Title:
  udev produces unpredictable net names when PCI device is a bridge

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]
  udev can produce unpredictable network interface names by default when 
multiple devices map to the same slot due to an intermediate bridge. On an 
Nvidia DGX2 system, I see the following when booting a system with udev 
245.4-4ubuntu3.13:

  ubuntu@akis:~$ ls /sys/class/net
  enp134s0f0  enp6s0  ens103  ens107  eth3  eth9
  enp134s0f1  ens102  ens106  eth1    eth7  lo

  For each ens* device, there is a sibling eth* device that maps to the
  same slot because both devices are behind the same bridge.

  Unpredictable names present well known problems, but I'll describe a
  specific issue I'm having. We currently do automated network testing
  that MAAS deploys a system and then configures 2 specific NICs on the
  system. While MAAS does take care to always restore the names used
  during commissioning (eth3 will always be the same NIC on every
  deploy), these names can change each time the system is commissioned.
  So today we need to go in and edit the NIC names manually in MAAS any
  time the system is re-commissioned.

  [Test Case]
  Boot with kernel option net.naming-scheme=v247; verify that all network 
interfaces receive predictable names.

  [Fix]
  This issue was addressed upstream by adding a new v247 naming scheme that 
detects this scenario and disables usage of slot-based names for these devices. 
Obviously changing the default naming scheme in a released LTS series could 
break users. However, we could introduce the v247 scheme in a focal SRU, and 
keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users 
impacted by this could then opt-in to the v247 scheme by passing 
net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. 
I could add this to DGX2 systems via a kernel_opts MAAS tag to always get 
predictable names during commissioning.

  [Regression Risk]
  This would change the behavior of any users who select 
net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm 
not sure why an existing Ubuntu user would be doing that though - AFAICT, 
Ubuntu currently always defaults to the latest scheme.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to