6

I'm running Debian Testing (kernel 5.10.0-2-amd64 / systemd 247.2-5) on a Mac Pro as a NAS / VM host. Today, I added a Thunderbolt 3 card (Gigabyte Titan Ridge) - and noticed something strange: the network identifiers of the Mac's built-in Ethernet ports (enp9s0 / enp10s0) change to enp14s0/enp15s0 depending on whether my iMac is attached and powered on via Thunderbolt at boot time.

What is causing this? I thought the advantage of the "new" naming scheme over good old "ethX" was that the device names are predictable. It is especially annoying as I have to hard-code the interface name in the GRUB commandline so that pre-boot DHCP works so that I can unlock the encrypted root disk, and I also need stable interface names for the bridge configuration.

(Additionally: neither boltctl nor tbtadm recognize the card or connected devices, but the kernel does, and network connectivity works just fine. Why?)

Improve this question
3
  • 3
    I suspect that's going to be Apple's fault and there's probably nothing systemd can really do about it. It really doesn't expect bus enumeration to return completely different results each boot unless hardware is physically moved around. I also guess Apple won't care because they only support macOS. That said, it might be worth filing a bug report with systemd just in case they can find some sort of way to deal with it. In this rare case you'll probably have to write udev rules to set your own device names for the NICs.
    – Michael Hampton
    Feb 23, 2021 at 19:07
  • 1
    The bus numbering is different when there are extra bus bridges attached, but persistent naming assumes that PCI bus numbering is persistent across boots.
    – Simon Richter
    Feb 23, 2021 at 19:08
  • See systemd.link you should be able to force the name you want by matching for example on the MAC address of the interface.
    – Patrick Mevzek
    Mar 11, 2021 at 14:51

1 Answer 1

Reset to default
10

That means hardware routing on this machine depends on whether anything is plugged into Thunderbolt socket. Remember, Thunderbolt's logical interface is PCIe, so you essentially plugging another device into the computer's system bus. In your Mac it happened that you plugging somewhat in the middle of the system bus, so it "pushes" everything past it further. This is how Apple laid out hardware bus; instead of reserving some pool of device numbers for each Thunderbolt port, or even counting each port as PCI bus on its own, they made these "ports" to appear or disappear in the system, shifting everything past them in some internal enumeration.

I've encountered the same issue with the PC, where network card device number depended on the condition of built-in soundcard: if sound card is enabled in BIOS Setup, it took NICs device number, and NIC itself received next in sequence. This is how hardware is laid out on that machine. Questions to the HW designer, why they didn't make Setup switch state of the "device in the virtual slot", and made the slot itself to appear or disappear.

Systemd's scheme has its advantages, but it depends exactly on device path, which for PCI is its device number and function; so, if device number changes, systemd thinks this is another card. So this scheme isn't relevant for environments where device number could change, so USB and Thunderbolt are particular places where it may fail.

Improve this answer
4
  • Thunderbolt wasn't even an option back in 2009, I added it with a PCI card. Your explanation does make sense since a lot of devices shift around in lspci between boots, thanks for the hint.Looks like I'll have to dig into uefi rules for actually persistent interface names...
    – user1933738
    Feb 23, 2021 at 21:18
  • I doubt any "UEFI rules" will help. I believe this has something to do with actual hardware design. We urgently need someone who is familiar with PCI spec to teach us! :)
    – Nikita Kipriyanov
    Feb 24, 2021 at 5:37
  • @user1933738 I think you mean udev rules.
    – Michael Hampton
    Feb 24, 2021 at 12:05
  • Turned out to be that indeed, thanks. I went and placed SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:00:xx:xx:xx", ATTR{type}=="1", NAME="eth_pri" in /etc/udev/rules.d/70-network.rules, fought with Debian to get this file into initramfs and now I don't have to worry any more.
    – user1933738
    Feb 27, 2021 at 19:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.