On 07/01/13 07:18, Dave Reisner wrote:
On Sun, Jan 06, 2013 at 09:32:41PM +0100, Tom Gundersen wrote:
On Jan 6, 2013 7:38 PM, "Dave Reisner" <d@falconindy.com> 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?
Upstream decision... vanilla packages should follow it.
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