[arch-dev-public] network interface naming with systemd 197

[Allan McRae]

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 at 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
> 
>