> I like the idea of the kernel command line argument because it is easy to apply and consistent across install types.
I agree the kernel boot param is absolutely easier, especially in the context of maas. TL;DR from me is: I think it's at least worth looking at using a link file, or some other simpler method for this specific situation/hardware; if that's significantly more work and/or more complex, I'm +1 on this MR. For more detail; my main objection to the MR is 2 things: 1) it would (in very limited situations) change the interface naming for anyone who is manually setting net-naming to 'latest' (which can be done either with a boot param, or editing the env var used by systemd-udevd). Why would anyone manually set that? I don't know for sure, since it is (and as you say, has long been) the default for ubuntu builds of systemd, but of course that's exactly the requirement for anyone to actually use the change introduced by the MR, so it's possible. 2) it doesn't actually fix this for anyone currently experiencing the problem; they would have to know about this change, and then take the extra step of manually setting the net-naming. So this really is a change that primarily benefits a very limited group of possibly affected users. Note that I don't think #2 is necessarily a blocker; I've done exactly that before, e.g. bug 304393. I do think your backport of the v247 naming scheme is the best way to handle this *if* there is no other way to address it (that isn't significantly more painful). -- 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
