Re: [arch-dev-public] network interface naming with systemd 197
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/PredictableNetworkInterfaceNames 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_id.c *** 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
Re: [arch-dev-public] network interface naming with systemd 197
On Jan 7, 2013 2:23 AM, "Andrea Scarpino" wrote: > > 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 Yep. And you're all correct. This will be enabled for new installs. Thanks for the feedback.
Re: [arch-dev-public] network interface naming with systemd 197
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
Re: [arch-dev-public] network interface naming with systemd 197
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" 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/pci:00/:00:1c.2/:05:00.0/net/eth0
>>> E: DEVPATH=/devices/pci:00/:00:1c.2/: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
>
>
Re: [arch-dev-public] network interface naming with systemd 197
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/pci:00/:00:1c.2/:05:00.0/net/eth0
> > E: DEVPATH=/devices/pci:00/:00:1c.2/: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
Re: [arch-dev-public] network interface naming with systemd 197
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/pci:00/:00:1c.2/:05:00.0/net/eth0
> E: DEVPATH=/devices/pci:00/:00:1c.2/: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).
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.
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.
Cheers,
Tom
Re: [arch-dev-public] network interface naming with systemd 197
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/pci:00/:00:1c.2/:05:00.0/net/eth0
> E: DEVPATH=/devices/pci:00/:00:1c.2/: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
[arch-dev-public] network interface naming with systemd 197
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/pci:00/:00:1c.2/:05:00.0/net/eth0
E: DEVPATH=/devices/pci:00/:00:1c.2/: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
