Comment 29 for bug 1437375

------- Comment From <email address hidden> 2015-06-22 22:42 EDT-------
Hi Maryn, I logged into your LPAR br14p07 and took a quick look, and I saw the updated 75-persistent-net-generator.rules file, and it does contain Brian's patch. And sure enough when I issued the command "udevadm trigger --subsystem-match=net --action=add", it added a record for eth0 that did not exist before:

root@br14p07:~# cat /etc/udev/rules.d/70-persistent-net.rules
...
# LPAR virtual device at 30000003 (ibmveth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="16:59:ce:bf:9b:03", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

I then rebooted the system but could not get back in since I did not have the PW for this node. However I could see that it was pingable after the reboot so I'm pretty sure the eth0 interface came back normally after the reboot. You can check that for me please.

So it looks like Brian's patch fixes it, at least as far a the udev rule in concerned. Now we need to know if you are still experiencing the problem you reported.

The above "udevadm trigger" simulates what happens when new interfaces are added or when the system first boots. For any interface we want to be persistent we should have a rule written to /etc/udev/rules.d/70-persistent-net.rules, and that should be working now for the partition LAN interfaces. Once the rule is there, the interface (eth0 in this case) should not move when other interfaces are added or removed, or the system is rebooted.

You can test various scenarios by deleting the /etc/udev/rules.d/70-persistent-net.rules file and allowing it to be recreated. So to test the scenario you reported here, I would delete the file and reboot the system, and ensure you have an entry for eth0 (like the one above) written to the 70-persistent-net.rules file after the reboot. Then, you should be able to hotplug the additional interfaces, and reboot, and eth0 should not move. If this does not happen let us know. Thx.