<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">cOn Fri, 16 Aug 2024 at 15:39, Henti Smith <<a href="mailto:henti@gaydonsmith.co.uk" target="_blank">henti@gaydonsmith.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 16 Aug 2024 at 07:31, Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
echo 'SUBSYSTEM=="net", KERNELS=="0000:00:10.0", NAME="mvc-sw1"' ><br>
/etc/udev/rules.d/mvc.rules<br>
echo 'SUBSYSTEM=="net", KERNELS=="0000:00:11.0", NAME="mvc-sw2"' >><br>
/etc/udev/rules.d/mvc.rules<br></blockquote><div><br></div><div><div>Thank you, this worked for me.  <br></div><div><br></div><div>I've updated my config to use the udev method, however can anybody explain to me what I did wrong with the systemd.link method ? <br></div><div><br></div><div>Based on the man page using Property=Path=pci-0000:05:00.0 Driver=oak should have worked to match the PCI address and the driver should it not ? <br></div></div></div></div></blockquote><div><br></div><div>Good day everybody. <br></div><div><br></div><div>Thank you again for the solution as noted above</div><div><br></div><div>After adding some more network devices to udev this way I now have the same udev configuration working intermittently and I'm not sure why. To create a complete picture I'll attach a collection of log files. <br></div><div><br></div><div>The zip contains two sets of logs from syslog and lshw when the udev works and when it doesn't. It's the same physical hardware without any changes and the udev file is exactly the same as well. I'll show some brief bits below: <br></div><div><br></div><div>The udev file in question is as follows:</div><div># Custom naming and Administratively-local MAC address for the two 10Gbit/s link to the Pony Gemini switch.<br># This ensures consistent naming and ordering regardless of whether the local debug board is attached. <br># It also means we don't need .link files in /etc/systemd/network for these two. <br>SUBSYSTEM=="net", KERNELS=="0000:00:0d.0", NAME="eno1"<br>SUBSYSTEM=="net", KERNELS=="0000:00:0c.0", NAME="debug1"<br>SUBSYSTEM=="net", KERNELS=="0000:00:10.0", NAME="mvc-sw1", RUN+="/sbin/ip link set dev mvc-sw1 address 02:00:00:00:05:00"<br>SUBSYSTEM=="net", KERNELS=="0000:00:11.0", NAME="mvc-sw2", RUN+="/sbin/ip link set dev mvc-sw2 address 02:00:00:00:06:00"<br></div><div><br></div><div>debug1 is the PCIe debug board that attaches to a hotplug port on the device to allow d-sub video access to the device, otherwise the device is headless. <br></div><div><br></div><div>We found that eno1 changes depending on when the debug board (debug1) is plugged in and not, so the additions are to ensure consistent device naming with it plugged in and not. <br></div><div><br></div><div>The udev file stat is:</div><div>root@av20-mvc-01:~# stat /lib/udev/rules.d/10-mvc-network.rules <br>  File: /lib/udev/rules.d/10-mvc-network.rules<br>  Size: 651             Blocks: 8          IO Block: 4096   regular file<br>Device: fd01h/64769d    Inode: 537062519   Links: 1<br>Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)<br>Access: 2024-08-21 13:26:57.914234146 +0000<br>Modify: 2024-08-20 15:42:33.749953979 +0000<br>Change: 2024-08-21 13:26:52.410092798 +0000<br> Birth: -<br></div><div><br></div><div>And afterwards I rebooted and shutdown the device several times and the resulting state was logged as follows: <br></div><div>2024-08-21T13:26:57.817412+00:00 av20-mvc-01 reboot                          : success<br>2024-08-21T13:29:05.833134+00:00 av20-mvc-01 shutdown -h 0 now     : fail<br>2024-08-21T13:33:23.672549+00:00 av20-mvc-01 reboot                          : success<br>2024-08-21T13:38:06.665489+00:00 av20-mvc-01 shutdown -h 0 now     : fail<br>2024-08-21T13:47:04.809970+00:00 av20-mvc-01 reboot                          : fail<br>2024-08-21T14:20:11.638717+00:00 av20-mvc-01 reboot                          : success<br></div><div><br></div><div>The syslog when the configuration worked is:</div><div>2024-08-21T13:19:07.318117+00:00 av20-mvc-01 systemd-networkd[1128]: eno1: Interface name change detected, eno1 has been renamed to debug1.<br>2024-08-21T13:19:07.318119+00:00 av20-mvc-01 systemd-networkd[1128]: eth1: Interface name change detected, eth1 has been renamed to eno1.<br>2024-08-21T13:19:07.315466+00:00 av20-mvc-01 systemd-networkd[1128]: eno1: Link UP<br>2024-08-21T13:19:07.319214+00:00 av20-mvc-01 kernel: [    4.601186] igb 0000:01:00.0 eno1: renamed from eth0<br>2024-08-21T13:19:07.319368+00:00 av20-mvc-01 kernel: [    8.331511] igb 0000:01:00.0 debug1: renamed from eno1<br>2024-08-21T13:19:07.319378+00:00 av20-mvc-01 kernel: [    8.374580] igb 0000:02:00.0 eno1: renamed from eth1<br>2024-08-21T13:19:07.319396+00:00 av20-mvc-01 kernel: [    8.611432] 8021q: adding VLAN 0 to HW filter on device eno1<br>2024-08-21T13:19:07.319396+00:00 av20-mvc-01 kernel: [    8.611927] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX<br>2024-08-21T13:19:07.854869+00:00 av20-mvc-01 systemd-networkd[1128]: eno1: Gained carrier</div><div><br></div><div>and when it failed:</div><div>2024-08-21T12:51:43.264195+00:00 av20-mvc-01 systemd-networkd[1130]: eno1: Link UP<br>2024-08-21T12:51:43.264214+00:00 av20-mvc-01 systemd-udevd[1037]: eth1: Failed to rename network interface 3 from 'eth1' to 'eno1': File exists<br>2024-08-21T12:51:43.264217+00:00 av20-mvc-01 systemd-udevd[1134]: eno1: Network interface 'eno1' is already up, cannot rename to 'debug1'.<br></div><div><br></div><div>What am I doing wrong here or what do I need to do differently to ensure that eno1 and debug1 are consistently named correctly ? <br></div><div><br></div><div>Kind regards</div><div>Henti<br></div></div></div>