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
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 11 fully signed off packages * 20 packages missing signoffs * 22 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [core] (9 total) == * b43-fwcutter-017-1 (i686) 0/2 signoffs * kbd-1.15.5-2 (i686) 1/2 signoffs * linux-3.7.1-2 (i686) 0/2 signoffs * lvm2-2.02.98-3 (i686) 1/2 signoffs * nfs-utils-1.2.6-4 (i686) 0/2 signoffs * xfsprogs-3.1.10-1 (i686) 1/2 signoffs * b43-fwcutter-017-1 (x86_64) 0/2 signoffs * nfs-utils-1.2.6-4 (x86_64) 1/2 signoffs * xfsprogs-3.1.10-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (11 total) == * refind-efi-0.6.2-1 (any) 0/2 signoffs * dmapi-2.2.12-1 (i686) 0/2 signoffs * lirc-1:0.9.0-35 (i686) 0/2 signoffs * nvidia-310.19-3 (i686) 0/2 signoffs * nvidia-304xx-304.64-2 (i686) 0/2 signoffs * php-apc-3.1.14-1 (i686) 0/2 signoffs * qemu-1.3.0-1 (i686) 0/2 signoffs * dmapi-2.2.12-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-35 (x86_64) 0/2 signoffs * nvidia-304xx-304.64-2 (x86_64) 0/2 signoffs * php-apc-3.1.14-1 (x86_64) 0/2 signoffs == Completed signoffs (11 total) == * cronie-1.4.9-2 (i686) * dhcpcd-5.6.4-1 (i686) * iptables-1.4.16.3-1 (i686) * cronie-1.4.9-2 (x86_64) * dhcpcd-5.6.4-1 (x86_64) * iptables-1.4.16.3-1 (x86_64) * kbd-1.15.5-2 (x86_64) * linux-3.7.1-2 (x86_64) * lvm2-2.02.98-3 (x86_64) * nvidia-310.19-3 (x86_64) * qemu-1.3.0-1 (x86_64) == All packages in [testing] for more than 14 days (22 total) == * lvm2-2.02.98-3 (i686), since 2012-11-03 * lvm2-2.02.98-3 (x86_64), since 2012-11-03 * dhcpcd-5.6.4-1 (i686), since 2012-12-06 * dhcpcd-5.6.4-1 (x86_64), since 2012-12-06 * iptables-1.4.16.3-1 (i686), since 2012-12-06 * iptables-1.4.16.3-1 (x86_64), since 2012-12-06 * nvidia-310.19-3 (i686), since 2012-12-11 * lirc-1:0.9.0-35 (i686), since 2012-12-11 * nvidia-304xx-304.64-2 (i686), since 2012-12-11 * nvidia-310.19-3 (x86_64), since 2012-12-11 * lirc-1:0.9.0-35 (x86_64), since 2012-12-11 * nvidia-304xx-304.64-2 (x86_64), since 2012-12-11 * dmapi-2.2.12-1 (i686), since 2012-12-19 * xfsprogs-3.1.10-1 (i686), since 2012-12-19 * dmapi-2.2.12-1 (x86_64), since 2012-12-19 * xfsprogs-3.1.10-1 (x86_64), since 2012-12-19 * kbd-1.15.5-2 (i686), since 2012-12-19 * kbd-1.15.5-2 (x86_64), since 2012-12-19 * qemu-1.3.0-1 (i686), since 2012-12-20 * qemu-1.3.0-1 (x86_64), since 2012-12-20 * linux-3.7.1-2 (i686), since 2012-12-20 * linux-3.7.1-2 (x86_64), since 2012-12-20 == Top five in signoffs in last 24 hours == 1. foutrelis - 3 signoffs 2. allan - 2 signoffs
