On Sun, Jan 06, 2013 at 01:38:03PM -0500, Dave Reisner wrote:

Just an FYI:

Upstream pushed a commit[0] which gives network devices persistent, and unique, names based on hardware attributes, avoiding the random kernel names. While this solves a real problem, it's also a fairly jarring change. For example:

$ udevadm info /sys/class/net/eth0 P: /devices/pci0000:00/0000:00:1c.2/0000:05:00.0/net/eth0 E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:05:00.0/net/eth0 E: ID_BUS=pci E: ID_MODEL_ID=0x4364 E: ID_NET_NAME_MAC=enxbcaec50bfcc8 E: ID_NET_NAME_PATH=enp5s0 E: ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC. E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_PRODUCT_FROM_DATABASE=88E8056 PCI-E Gigabit Ethernet Controller E: ID_VENDOR_FROM_DATABASE=Marvell Technology Group Ltd. E: ID_VENDOR_ID=0x11ab E: IFINDEX=2 E: INTERFACE=eth0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0 E: TAGS=:systemd: E: USEC_INITIALIZED=42063

If I were to reboot right now (systemd-git), eth0 would become enp5s0. I tend to think that this is fairly extreme, and would throw off a lot of people -- especially those who never needed to deal with interface renaming.

For systemd 197, I plan on shipping this rule as documentation in /usr/share/doc/systemd and _not_ enabling it by default. Those who want to opt in can simply copy the rule to /etc/udev/rules.d. They can also, of course, continue to use whatever MAC-based rules they might have, but I would strongly recommend switching these rules to be triggered by ID_NET_NAME_{SLOT,PATH,ONBOARD} instead.

Cheers, Dave

[0] http://cgit.freedesktop.org/systemd/systemd/commit/?id=394e2938ff9

Alternatively, we could simply write a symlink to /dev/null on post_upgrade to 197 and post_install() if /etc/udev/rules.d/80-net-name-slot.rules doesn't exist. I don't particularly care either way, since both methods are a matter of documentation to enable it. I'll point out that masking has the advantage of not needing to worry about changes to the upstream rule when a user opts in to interface renaming. d

On Sun, Jan 06, 2013 at 09:32:41PM +0100, Tom Gundersen wrote:

On Jan 6, 2013 7:38 PM, "Dave Reisner" wrote:

...

Just an FYI:

Upstream pushed a commit[0] which gives network devices persistent, and unique, names based on hardware attributes, avoiding the random kernel names. While this solves a real problem, it's also a fairly jarring change. For example:

$ udevadm info /sys/class/net/eth0 P: /devices/pci0000:00/0000:00:1c.2/0000:05:00.0/net/eth0 E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:05:00.0/net/eth0 E: ID_BUS=pci E: ID_MODEL_ID=0x4364 E: ID_NET_NAME_MAC=enxbcaec50bfcc8 E: ID_NET_NAME_PATH=enp5s0 E: ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC. E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_PRODUCT_FROM_DATABASE=88E8056 PCI-E Gigabit Ethernet Controller E: ID_VENDOR_FROM_DATABASE=Marvell Technology Group Ltd. E: ID_VENDOR_ID=0x11ab E: IFINDEX=2 E: INTERFACE=eth0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0 E: TAGS=:systemd: E: USEC_INITIALIZED=42063

If I were to reboot right now (systemd-git), eth0 would become enp5s0. I tend to think that this is fairly extreme, and would throw off a lot of people -- especially those who never needed to deal with interface renaming.

For systemd 197, I plan on shipping this rule as documentation in /usr/share/doc/systemd and _not_ enabling it by default. Those who want to opt in can simply copy the rule to /etc/udev/rules.d. They can also, of course, continue to use whatever MAC-based rules they might have, but I would strongly recommend switching these rules to be triggered by ID_NET_NAME_{SLOT,PATH,ONBOARD} instead.

Cheers, Dave

[0] http://cgit.freedesktop.org/systemd/systemd/commit/?id=394e2938ff9

How about:

1) follow upstream on fresh installs (i.e. ship the rule and don't mask it in post_instal).

Scary. I agree with upstream that this is wanted and that it solves real problems, but I really see no reason that this should be opt-out, rather than opt-in. We have the option of explaining why the dummy file exists in /etc when we make things opt-in, but opt-out on install makes the messaging easier to miss. Additionally, there'll be an awkward phase where older install media uses older systemd (providing the "classic" names), followed by a reboot into newer systemd with the new naming scheme. Anyone else have an opinion on this?

2) stay backwards compatible on upgrade (i.e. mask the rule in post_upgrade).

3) print a notice about the masking so people can unmask it.

Definitely planned.

4) rather than a symlink to null, use an empty rules file with a comment explaining why it is there and what will happen if you delete it.

I like this. Done for the -git package, at least. d

On Monday 07 January 2013 07:51:30 Allan McRae wrote:

Upstream decision... vanilla packages should follow it.

I agree with Allan. We don't use to change the default behavior. Ship it as default and add two lines on how to disable it. -- Andrea Arch Linux Developer

If you don't care about interface renaming with systemd 197 or you understand the change, you can stop reading here. I suggest everyone read the first point, though. ---------------------- Since 197 was just tagged and there still seems to be some confusion, here's an FAQ: *** What happens after installing systemd 197? For existing installs: Nothing happens, and this is strictly opt-in. A post_upgrade() message will mention the feature and add a dummy file called /etc/udev/rules.d/80-net-name-slot.rules to mask the new rule which performs the renaming. If you wish to opt-in, remove this dummy file. Next reboot, the rule will take effect. For new installs: You are opted-in to this change. The post_install() will do nothing to mask the rule. If you wish to opt out, you can do 1 of 2 things: 1) mask the rule: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules 2) provide your own udev rule that applies a NAME to the interface. As long as this rule is ordered lexically before 80-net-name-slot.rules, then the upstream rule will have no effect. For example, providing a file called 70-net-naming.rules will trump 80-net-name-slot.rules. *** What will the interfaces be renamed to if I opt-in? Run this as non-root: for i in /sys/class/net/*; do echo "==$i" udevadm test-builtin net_id "$i"; echo done 2>/dev/null Not all interfaces will have output for this command. No output means no renaming. For those that do, the below properties are capable of renaming the device, with highest priority first. - ID_NET_NAME_ONBOARD - ID_NET_NAME_SLOT - ID_NET_NAME_PATH So for an interface with both ID_NET_NAME_ONBOARD and ID_NET_NAME_PATH, the value of ID_NET_NAME_ONBOARD will be the new name of the interface. If you see none of these properties for an interface, it will not be renamed by /usr/lib/udev/rules.d/80-net-name-slot.rules. *** How should I go about updating my network config? I suggest figuring out what your device will be named in advance and altering your config BEFORE rebooting. Consult the documentation for your network provider on how to do this. If you don't want to do this, read the next 2 questions. *** I don't like this, or, I've never needed persistent names You'll never be forced to use the new schema. Masking the rule as explained above will always work, and you're still able to write a rule of your own to provide names you're comfortable with if that's what you're into. *** Is there any way to alias the old kernel name to the new name? No, the kernel does not support this. *** Need more info? Upstream wrote a wiki page with more detail. Some of this is redundant with the above: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface... The careful reader might notice that names are path based. Yes, this does mean that USB devices or PCI devices which are physically moved to another port will suddenly change names. That's the trade-off for this scheme. *** STILL not satisfied? Code is the ultimate documentation, and has some examples of how various paths translate into the new naming scheme: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_i... *** Why are you still reading this? If you made it this far, you might be as crazy as I am, so here's Pinkie Pie dressed as a chicken: http://i.imgur.com/DDukE.png Cheers, Dave