Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED
On 1 April 2013 02:56, Philip Webb purs...@ca.inter.net wrote: I have sent a msg to gentoo-user describing how to solve this problem. Perhaps it needs to be mentioned in the news item or wiki entry. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca So you broke the threading on the original email, you deleted all the previous content, you did not write an appropriate title for your e-mail and then you claim you solved a problem without mentioning what the problem was. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED
130401 Markos Chandras wrote: On 1 April 2013 02:56, Philip Webb purs...@ca.inter.net wrote: I have sent a msg to gentoo-user describing how to solve this problem. Perhaps it needs to be mentioned in the news item or wiki entry. So you broke the threading on the original email, you deleted all the previous content, you did not write an appropriate title for your e-mail and then you claim you solved a problem without mentioning what the problem was. Your response is completely out of place very impolite. I am trying to help improve Gentoo documentation help other users who may face the same problem, but without taking unnecessary space on the dev-list. I am not happy with the way the Udev-200 update has been documented, but I haven't criticised the developer responsible. Please take the trouble to read what I sent to the user-list : Date: Sun, 31 Mar 2013 21:54:08 -0400 From: Philip Webb purs...@ca.inter.net To: Gentoo User gentoo-u...@lists.gentoo.org Subject: [gentoo-user] Udev 200 : dhcpcd problem + solution Message-ID: 20130401015408.ga...@ca.inter.net -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED
On 1 April 2013 16:32, Philip Webb purs...@ca.inter.net wrote: 130401 Markos Chandras wrote: On 1 April 2013 02:56, Philip Webb purs...@ca.inter.net wrote: I have sent a msg to gentoo-user describing how to solve this problem. Perhaps it needs to be mentioned in the news item or wiki entry. So you broke the threading on the original email, you deleted all the previous content, you did not write an appropriate title for your e-mail and then you claim you solved a problem without mentioning what the problem was. Your response is completely out of place very impolite. I am trying to help improve Gentoo documentation help other users who may face the same problem, but without taking unnecessary space on the dev-list. I am not happy with the way the Udev-200 update has been documented, but I haven't criticised the developer responsible. Please take the trouble to read what I sent to the user-list : Oh but of course. This was more than obvious. Posting something to gentoo-dev just to inform us that you posted something to gentoo-user without even mentioning the title. And then you claim that my reply is out of place. Ok -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED
On 04/01/2013 01:06 PM, Markos Chandras wrote: On 1 April 2013 16:32, Philip Webb purs...@ca.inter.net wrote: 130401 Markos Chandras wrote: On 1 April 2013 02:56, Philip Webb purs...@ca.inter.net wrote: I have sent a msg to gentoo-user describing how to solve this problem. Perhaps it needs to be mentioned in the news item or wiki entry. So you broke the threading on the original email, you deleted all the previous content, you did not write an appropriate title for your e-mail and then you claim you solved a problem without mentioning what the problem was. Your response is completely out of place very impolite. I am trying to help improve Gentoo documentation help other users who may face the same problem, but without taking unnecessary space on the dev-list. I am not happy with the way the Udev-200 update has been documented, but I haven't criticised the developer responsible. Please take the trouble to read what I sent to the user-list : Oh but of course. This was more than obvious. Posting something to gentoo-dev just to inform us that you posted something to gentoo-user without even mentioning the title. And then you claim that my reply is out of place. Ok Is this a good time to point out that list archival is still broken? And has been for almost a year? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED
On Apr 1, 2013 8:53 PM, Michael Mol mike...@gmail.com wrote: On 04/01/2013 01:06 PM, Markos Chandras wrote: On 1 April 2013 16:32, Philip Webb purs...@ca.inter.net wrote: 130401 Markos Chandras wrote: On 1 April 2013 02:56, Philip Webb purs...@ca.inter.net wrote: I have sent a msg to gentoo-user describing how to solve this problem. Perhaps it needs to be mentioned in the news item or wiki entry. So you broke the threading on the original email, you deleted all the previous content, you did not write an appropriate title for your e-mail and then you claim you solved a problem without mentioning what the problem was. Your response is completely out of place very impolite. I am trying to help improve Gentoo documentation help other users who may face the same problem, but without taking unnecessary space on the dev-list. I am not happy with the way the Udev-200 update has been documented, but I haven't criticised the developer responsible. Please take the trouble to read what I sent to the user-list : Oh but of course. This was more than obvious. Posting something to gentoo-dev just to inform us that you posted something to gentoo-user without even mentioning the title. And then you claim that my reply is out of place. Ok Is this a good time to point out that list archival is still broken? And has been for almost a year? I don't see how this is relevant to this discussion. We are aware of that. The bug is still open
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 04:45:50PM +0200, Samuli Suominen wrote Those 70-* and 80-* are in udev pkg_postinst, this news item, everywhere... can all 3 be deleted if you haven't modified them yourself. So that leaves one... local.rules... dunno about that. I'm curious. One paragraph you should add to the news item is... === Users who change interface names will need to search, as root, for references to eth[0-9] in their config files. Then they will have to change the config files to reflect the new names. At least the following search is suggested... grep -rl eth[0-9] /etc /var/lib Also any custom firewall/routing/network scripts in other locations should be searched for references to eth[0-9]. === -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
Am Sonntag, 31. März 2013, 03:17:52 schrieb Samuli Suominen: Nothing is stopping you from leaving out the symlink either and migrating to the new name despite using only 1 network card either, it's still more reliable than the kernel names Why should I? Kernel behaviour is traditionally way more stable than udev behaviour. If my driver for my only one network card has always produced eth0 as device name, chances are good it will do so still in a few years, after re-shuffling the cards in my casing, and even after exchanging the whole motherboard. Whereas with udev I can probably expect random things at random times for each of these events. Also, should I have problems with a new kernel, I can always just boot back into an old one without much ado. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
130331 Samuli Suominen offered prompt + polite help re Udev 200 : Thanks. In fact, it's a bit more complex than I thought yesterday. After moving the '70 80' files into a subdirectory restarting, I get : root:501 ~ dhcpcd dhcpcd[830]: version 5.6.4 starting ... [nothing happens for 10 s ] ^C ... [long delay till machine responds] dhcpcd[830]: no interfaces have a carrier dhcpcd[830]: forked to background, child pid 857 root:502 ~ dhcpcd dhcpcd[864]: version 5.6.4 starting dhcpcd[864]: enp5s0: sending IPv6 Router Solicitation dhcpcd[864]: enp5s0: rebinding lease of 192.168.1.2 dhcpcd[864]: enp5s0: NAK: from 192.168.1.1 dhcpcd[864]: enp5s0: sending IPv6 Router Solicitation dhcpcd[864]: enp5s0: broadcasting for a lease dhcpcd[864]: enp5s0: offered 192.168.1.2 from 192.168.1.1 dhcpcd[864]: enp5s0: acknowledged 192.168.1.2 from 192.168.1.1 dhcpcd[864]: enp5s0: checking for 192.168.1.2 dhcpcd[864]: enp5s0: sending IPv6 Router Solicitation dhcpcd[864]: enp5s0: leased 192.168.1.2 for 86400 seconds dhcpcd[864]: forked to background, child pid 888 The same happens if I try 'dhcpcd enp5s0', except that the 1st reply is enp5s0 : removing interface. The name 'enp5s0' has shown up after 1 restart, so that seems to be what my kernel (gentoo-sources 3.5.3) calls it. So I've done what I understand to be recommended, but have to go thro' a stutter before I can get the I/net working. I really don't want to have to spend an hour or more reading docs which are largely irrelevant to my very simple case, ie 1 network card accessing an ordinary ISP. Further advice is very welcome I hope I'm helping clarify things for others trying who try to follow the news item also helping the developer improve his docs. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED
I have sent a msg to gentoo-user describing how to solve this problem. Perhaps it needs to be mentioned in the news item or wiki entry. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
130329 Samuli Suominen wrote: Attached new version again, more generic than before. I find this difficult to decipher. Who is it aimed at ? I've just updated to Udev 200 . Following the news item, I renamed /etc/udev/rules.d/70-persistent-net.rules : my script to start my I/net connection with DHCP failed. I restored the file to its old name all works as usual : it has 'NAME=eth0'. I am always aware of grateful for the unpaid efforts of Gentoo devs, but I'm not pleased with confused or confusing news items. The first thing any news item should make clear is its audience : If you are using ABC or belong to the group describable as DEF, then you need to do GHI. Clearly, I don't fall into the group at whom the Udev news item is aimed, perhaps those with 1 net card. What proportion of Gentoo users fall into that group ? HTH improve news items. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 31/03/13 04:06, Philip Webb wrote: 130329 Samuli Suominen wrote: Attached new version again, more generic than before. I find this difficult to decipher. Who is it aimed at ? I've just updated to Udev 200 . Following the news item, I renamed /etc/udev/rules.d/70-persistent-net.rules : my script to start my I/net connection with DHCP failed. I restored the file to its old name all works as usual : it has 'NAME=eth0'. Aimed to everyone and it already answers your questions. I can answer them differently here again, but if you read the news item, this all is there: If kernel assigns eth0 to first network interface (driver/module) then you can't rename to eth0, thus the rule you have is likely superflous and it doesn't matter if you delete it or not -- you are currently using random kernel names What it might do is interfere with enabling of the new networking, so you should propably symlink /etc/udev/rules.d/80-net-name-slot.rules to /dev/null and delete the 70-persistent-net.rules and the behavior of your system stays exactly as it's when you are writing this now, using random kernel names, but if it's an system with only 1 network card, it propably doesn't matter much as eth0 gets always used (almost always) Nothing is stopping you from leaving out the symlink either and migrating to the new name despite using only 1 network card either, it's still more reliable than the kernel names The logic really isn't that hard... It's documented everywhere... :-(
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 31/03/2013 03:17, Samuli Suominen wrote: it's still more reliable than the kernel names I still call that bullshit. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 12:24, Duncan wrote:
Samuli Suominen posted on Fri, 29 Mar 2013 10:09:27 +0200 as excerpted:
This feature will also replace the functionality of sys-apps/biosdevname
which you should uninstall. However, you can still keep using
sys-apps/biosdevname if you want.
I'd suggest...
This feature can optionally replace... can uninstall.
IOW...
s/will also/can optionally/
s/should/can/
It sounds less menacing than your suggested wording, making it clearer
that it's an optional replacement and lessening the apparent conflict and
possible confusion with the next sentence saying it can still be used if
desired.
I'd say that's a particularly good idea given the sensitivity around the
all engulfing gray goo that systemd has seemed to many to have become.
Given that upstream specifically designed this feature to cooperate with
existing biosdevname installations, let's not unnecessarily poke that
hornet's nest by implying otherwise, even if the next sentence /does/
basically say it's an optional change anyway. =:^/
OK, new one attached, should be better
Title: The new default predictable network interface naming with udev
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2013-03-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-201
If you still have network interface renaming rules in /etc/udev/rules.d,
like 70-persistent-net.rules, you will need to modify or remove them.
If you choose to modify them, you will need to pick a free namespace (like
net* or internet*) that is not reserved by the kernel (like eth* or wlan*)
because in-place renaming has been deprecated[1].
You should also rename the file to something else, like 70-my-network.rules
to silence the deprecation warning coming from when you emerge udev.
This is old format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=eth0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=eth1
This is new format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=net0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=net1
With the new predictable network interface naming scheme which upstream enabled
by default you don't have to rename anymore because the names will be static
and not randomly rename when you, for example, upgrade the kernel. This can be
very important aspect, for example, security in mind.
If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a
symlink to /dev/null, the new names will be disabled and kernel will do
all the interface naming, which will be random.
The new names can also be disabled using net.ifnames=0 kernel option.
In normal new installation there is no files put in /etc/udev/rules.d and if
you haven't edited any files you have in there, you should most likely delete
(backup) them all out of the way.
You can find out using udevadm command what your interfaces will be called
before booting to make necessary changes, such as changing net.* symlinks
in /etc/init.d.
This is the example command:
# udevadm test-builtin net_id /sys/class/net/eth0 2 /dev/null
The output could be (and I'm only picking the most important line for this
example):
ID_NET_NAME_PATH=enp2s0f0
This would mean your eth0 will be called enp2s0f0 if there is no previously
mentioned files blocking the new names taking place in /etc/udev/rules.d.
This is documented more throughly at upstream wiki[2] which everyone should
read at least once.
This feature can also replace the functionality of sys-apps/biosdevname, but
you can still keep using it if you want.
[1] http://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 11:26, Samuli Suominen wrote: With the new predictable network interface naming scheme which upstream enabled by default you don't have to rename anymore because the names will be static and not randomly rename when you, for example, upgrade the kernel. This can be very important aspect, for example, security in mind. You do know this is false, right? The names are supposed to be predictable, not persistent. If you do happen to MOVE your network card because the new videocard you add to your system does not fit otherwise, the name _will_ change. If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, which will be random. Avoid spreading FUD about naming being random. Thanks. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 12:46, Diego Elio Pettenò wrote: On 29/03/2013 11:26, Samuli Suominen wrote: With the new predictable network interface naming scheme which upstream enabled by default you don't have to rename anymore because the names will be static and not randomly rename when you, for example, upgrade the kernel. This can be very important aspect, for example, security in mind. You do know this is false, right? The names are supposed to be predictable, not persistent. If you do happen to MOVE your network card because the new videocard you add to your system does not fit otherwise, the name _will_ change. Not false, but configurable, and linked from the news item -- nobody stopping you from eg. using MAC addresses instead of PCI slots for defining the names, just like one would have renamed them using MAC with 70-persistent-net.rules If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, which will be random. Avoid spreading FUD about naming being random. Thanks. Not FUD, but a fact, depends on the driver code (in kernel) if it'll change or not That's random enough as we can't force people to track kernel source tree and drivers code
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 11:50, Samuli Suominen wrote: Not false, but configurable, and linked from the news item -- nobody stopping you from eg. using MAC addresses instead of PCI slots for defining the names, just like one would have renamed them using MAC with 70-persistent-net.rules Which I usually do. But With the new predictable ... scheme ... the names will be static and not randomly rename ... is false. The name will be predictable before rebooting (maybe?) but it could very easily change randomly on udev update. Not FUD, but a fact, depends on the driver code (in kernel) if it'll change or not That's random enough as we can't force people to track kernel source tree and drivers code Hm hm. It's still FUD. If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. Whereas, with the new predictable scheme, if I move that card around, it will change name. Tell me which one is random, again? --- I'm not saying you shouldn't enable it (feel free to screw up user as much as you want, just don't complain if they don't like you), but since both kernel naming and predictable naming have their chance to change, don't spread FUD. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 13:01, Diego Elio Pettenò wrote:
On 29/03/2013 11:50, Samuli Suominen wrote:
Not false, but configurable, and linked from the news item -- nobody
stopping you from eg. using MAC addresses instead of PCI slots for
defining the names, just like one would have renamed them using MAC with
70-persistent-net.rules
Which I usually do. But
With the new predictable ... scheme ... the names will be static and
not randomly rename ...
is false.
The name will be predictable before rebooting (maybe?) but it could very
easily change randomly on udev update.
Not FUD, but a fact, depends on the driver code (in kernel) if it'll
change or not
That's random enough as we can't force people to track kernel source
tree and drivers code
Hm hm. It's still FUD.
If my desktop only has one Ethernet interface, no matter how many kernel
changes happen, it'll always be eth0.
Whereas, with the new predictable scheme, if I move that card around, it
will change name.
Tell me which one is random, again?
I see. You politely wanted to point out these lacks in the news item.
Sorry, it was hard to see it through from all the sarcasm.
(New item attached, and also covers ulm's concerns from the another reply.)
---
I'm not saying you shouldn't enable it (feel free to screw up user as
much as you want, just don't complain if they don't like you),
I don't remember complaining about users not liking me, nor caring about
it. If they want to shoot the messenger, that's fine by me.
but since
both kernel naming and predictable naming have their chance to change,
don't spread FUD.
One you can control, the another you can't. So still not FUD.
Title: The new predictable net iface names
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2013-03-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-201
If you still have network interface renaming rules in /etc/udev/rules.d,
like 70-persistent-net.rules, you will need to modify or remove them.
If you choose to modify them, you will need to pick a free namespace
(like net* or internet*) that is not reserved by the kernel
(like eth* or wlan*) because in-place renaming has been deprecated[1].
You should also rename the file to something else, like
70-my-network.rules to silence the deprecation warning coming from when
you emerge udev.
This is old format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=eth0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=eth1
This is new format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=net0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=net1
With the new predictable network interface naming scheme which upstream
enabled by default you don't have to rename anymore because the names
will be static and not randomly rename when you, for example, upgrade
the kernel. The default name is calculated from the slot being used for
the card, but it can be changed to be, for example, MAC based. This is
documented in the upstream wiki[2]. This can be very important aspect,
for example, security in mind.
If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, which will be random.
The new names can also be disabled using net.ifnames=0 kernel option.
However, if your system has only one network interface card,
for example, eth0, you don't necessarily need this feature at all.
Use the forementioned methods to disable the feature in that case if
you want.
In normal new installation there is no files put in /etc/udev/rules.d
and if you haven't edited any files you have in there, you should most
likely delete (backup) them all out of the way.
You can find out using udevadm command what your interfaces will be
called before booting to make necessary changes, such as changing
net.* symlinks in /etc/init.d.
This is the example command:
# udevadm test-builtin net_id /sys/class/net/eth0 2 /dev/null
The output could be (and I'm only picking the most important line for
this example):
ID_NET_NAME_PATH=enp2s0f0
This would mean your eth0 will be called enp2s0f0 if there is no
previously mentioned files blocking the new names taking place in
/etc/udev/rules.d.
This is documented more throughly at upstream wiki[2] which everyone
should read at least once.
This feature can also replace the functionality of sys-apps/biosdevname,
but you can still keep using it if you want.
[1] http://www.kernel.org/doc/htmldocs/device-drivers/
API-device-rename.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Whereas, with the new predictable scheme, if I move that card around, it will change name. It's even worse, if you mess with kernel parameters (esp. pci=assign-busses for PCMCIA) then the device numbering might change without hardware moving around. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 12:29, Samuli Suominen wrote: One you can control, the another you can't. So still not FUD. You do not really control it any more than the kernel. The fact that me and you can edit an udev ruleset to control it, does not mean that most users see it as a black box. The news item reads better. I would still either avoid showing the NET_PATH example or describe that that is not the final result because on a laptop, NET_PATH almost certainly will *not* match the final interface name: flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1 2/dev/null ID_NET_NAME_MAC=enx0026b9d7bf1f ID_OUI_FROM_DATABASE=Dell Inc ID_NET_NAME_ONBOARD=eno1 ID_NET_LABEL_ONBOARD=en Onboard LAN ID_NET_NAME_PATH=enp0s25 And I would not expect users to all go read the wiki and try to figure out why you said it would be named enp0s25 when it gets the name eno1. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Okay let me re-qualify the statement: If my desktop only has one Ethernet interface, and I don't mess up with it in userspace at all, no matter how many kernel changes happen, it'll always be eth0. Yes, the previous persistent rules for udev would have messed that one up when e1000e got split, or if you switched between the Broadcom-provided driver to the kernel one or vice-versa. The deathforce drivers come in mind as well. Whereas, with the new predictable scheme, if I move that card around, it will change name. It's even worse, if you mess with kernel parameters (esp. pci=assign-busses for PCMCIA) then the device numbering might change without hardware moving around. Sweet I didn't think about that. Yai for predictably variable names. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 13:38, Diego Elio Pettenò wrote:
On 29/03/2013 12:29, Samuli Suominen wrote:
One you can control, the another you can't. So still not FUD.
You do not really control it any more than the kernel. The fact that me
and you can edit an udev ruleset to control it, does not mean that
most users see it as a black box.
I don't agree with that, /etc/udev/rules.d and overriding udev rules is
very basic administration, very basic...
I'll put a bit more trust on our users.
The news item reads better. I would still either avoid showing the
NET_PATH example or describe that that is not the final result because
on a laptop, NET_PATH almost certainly will *not* match the final
interface name:
flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1 2/dev/null
ID_NET_NAME_MAC=enx0026b9d7bf1f
ID_OUI_FROM_DATABASE=Dell Inc
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=en Onboard LAN
ID_NET_NAME_PATH=enp0s25
And I would not expect users to all go read the wiki and try to figure
out why you said it would be named enp0s25 when it gets the name eno1.
Nod.
Attached new version again, more generic than before.
Hope it'll do what it's meant to do... push users into right direction...
It's not meant to be a complete documentation or rewrite of the upstream
wiki page :-p
Just a push...
Title: The new predictable net iface names
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2013-03-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-201
If you still have network interface renaming rules in /etc/udev/rules.d,
like 70-persistent-net.rules, you will need to modify or remove them.
If you choose to modify them, you will need to pick a free namespace
(like net* or internet*) that is not reserved by the kernel
(like eth* or wlan*) because in-place renaming has been deprecated[1].
You should also rename the file to something else, like
70-my-network.rules to silence the deprecation warning coming from when
you emerge udev.
This is old format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=eth0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=eth1
This is new format:
SUBSYSTEM==net, ACTION==add, ATTR{address}==xx:xx:xx:xx:xx:xx,
NAME=net0
SUBSYSTEM==net, ACTION==add, ATTR{address}==yy:yy:yy:yy:yy:yy,
NAME=net1
With the new predictable network interface naming scheme which upstream
enabled by default you don't have to rename anymore because the names
will be static and not randomly rename when you, for example, upgrade
the kernel. The default names can be calculated from the slots being
used for the cards, but it can be changed to use, for example, MAC
addresses. This is documented in the upstream wiki[2].
If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, which will be random.
The new names can also be disabled using net.ifnames=0 kernel option.
However, if your system has only one network interface card,
for example, eth0, you don't necessarily need this feature at all.
Use the forementioned methods to disable the feature in that case if
you want.
In normal new installation there is no files put in /etc/udev/rules.d
and if you haven't edited any files you have in there, you should most
likely delete (backup) them all out of the way.
You can find out using udevadm command what your interfaces will be
called before booting to make necessary changes, such as changing
net.* symlinks in /etc/init.d.
This is the example command for getting attributes of the current eth0
network device:
# udevadm test-builtin net_id /sys/class/net/eth0 2 /dev/null
Assuming there are no leftover rules in /etc/udev/rules.d that would
prevent the new names from being enabled, it's most likely either
ID_NET_NAME_ONBOARD or ID_NET_NAME_PATH lines you should be looking
at for the new name in default configuration. This ordering is
documented more throughly at upstream wiki[2] which everyone should
read at least once.
This feature can also replace the functionality of sys-apps/biosdevname,
but you can still keep using it if you want.
[1] http://www.kernel.org/doc/htmldocs/device-drivers/
API-device-rename.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 13:20, Samuli Suominen wrote: I don't agree with that, /etc/udev/rules.d and overriding udev rules is very basic administration, very basic... I'll put a bit more trust on our users. Let's agree to disagree then. To me, it's much more consistent the kernel's behaviour than these predictable names. Is my WWAN interface wwan0, wwp0s29u1u2i1, wws1u1i1 or wwp0s29u1u3i1 today? Attached new version again, more generic than before. Hope it'll do what it's meant to do... push users into right direction... It's not meant to be a complete documentation or rewrite of the upstream wiki page :-p Better, not perfect IMHO, but definitely better. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 03/29/2013 08:20 AM, Samuli Suominen wrote: On 29/03/13 13:38, Diego Elio Pettenò wrote: On 29/03/2013 12:29, Samuli Suominen wrote: One you can control, the another you can't. So still not FUD. You do not really control it any more than the kernel. The fact that me and you can edit an udev ruleset to control it, does not mean that most users see it as a black box. I don't agree with that, /etc/udev/rules.d and overriding udev rules is very basic administration, very basic... I'd love to believe that, but do you have any idea how many people aren't familiar with it? It took a long time before the default response to help, I've replaced my NIC or motherboard, and eth0 is gone! became find and remove this line from /etc/udev/rules.d/70-persistent-net.rules instead of remove /etc/udev/rules.d/70-persistent-net.rules Something else...I've not encountered *one* other person to use anything other than the system-default names for NICs...except myself. And when I've done it, and despite giving them descriptive names, other people are completely flummoxed when they see my configurations. What's this 'wan', 'lan' and 'wifilan'? Where are eth0, eth1 and eth2? And of those I've found who knew of the feature and knew how to use it, none have ever felt motivated to use it except when hardware was replaced. (Personally, I find the feature underused; I could easily see networks benefiting from rules like any interface prefixed with 'p' is public facing without the benefit of a firewall, any interface prefixed with 's' points to a SAN or any interface prefixed with a 'c' is touches a network region where PCI-compliance rules are in effect.) I'll put a bit more trust on our users. The news item reads better. I would still either avoid showing the NET_PATH example or describe that that is not the final result because on a laptop, NET_PATH almost certainly will *not* match the final interface name: flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1 2/dev/null ID_NET_NAME_MAC=enx0026b9d7bf1f ID_OUI_FROM_DATABASE=Dell Inc ID_NET_NAME_ONBOARD=eno1 ID_NET_LABEL_ONBOARD=en Onboard LAN ID_NET_NAME_PATH=enp0s25 And I would not expect users to all go read the wiki and try to figure out why you said it would be named enp0s25 when it gets the name eno1. Nod. Attached new version again, more generic than before. Hope it'll do what it's meant to do... push users into right direction... It's not meant to be a complete documentation or rewrite of the upstream wiki page :-p Just a push... I would probably replace this: If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, which will be random. With something like this: If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's a symlink to /dev/null, the new names will be disabled and kernel will do all the interface naming, and the resulting names will vary by kernel and hardware configuration, and may vary by kernel version. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
Am Freitag, 29. März 2013, 13:20:20 schrieb Samuli Suominen: On 29/03/13 13:38, Diego Elio Pettenò wrote: On 29/03/2013 12:29, Samuli Suominen wrote: One you can control, the another you can't. So still not FUD. You do not really control it any more than the kernel. The fact that me and you can edit an udev ruleset to control it, does not mean that most users see it as a black box. I don't agree with that, /etc/udev/rules.d and overriding udev rules is very basic administration, very basic... I'll put a bit more trust on our users. Not really. Every time I modified anything in there, it just took a few udev versions and suddenly I was flooded with deprecation warnings a la things work different now, find out on your own how to fix it... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 9:24 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Not really. Every time I modified anything in there, it just took a few udev versions and suddenly I was flooded with deprecation warnings a la things work different now, find out on your own how to fix it... Not to mention at least in the past it has tended to accumulate orphans. I was getting tons of warnings on boot-up and discovered that config protection left a ton of files in there from who-knows-when. Granted, this is on a system that has been running Gentoo for about a decade now (every part in it has changed several times, but the OS has steadily migrated along). Now I'm down to 5 files in there, and only one of them is my local.rules file. If udev is going to stick stuff in /etc then it really needs to have better communication when this stuff needs to be modified/cleaned/etc, and what users are and aren't supposed to touch. Rich
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 15:30, Rich Freeman wrote: On Fri, Mar 29, 2013 at 9:24 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Not really. Every time I modified anything in there, it just took a few udev versions and suddenly I was flooded with deprecation warnings a la things work different now, find out on your own how to fix it... Not to mention at least in the past it has tended to accumulate orphans. I was getting tons of warnings on boot-up and discovered that config protection left a ton of files in there from who-knows-when. Granted, this is on a system that has been running Gentoo for about a decade now (every part in it has changed several times, but the OS has steadily migrated along). Now I'm down to 5 files in there, and only one of them is my local.rules file. If udev is going to stick stuff in /etc then it really needs to have better communication when this stuff needs to be modified/cleaned/etc, and what users are and aren't supposed to touch. Rich What do you have there? We cover bunch of those in pkg_postinst of udev already.
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 9:44 AM, Samuli Suominen ssuomi...@gentoo.org wrote: What do you have there? We cover bunch of those in pkg_postinst of udev already. After a bunch of cleanup (after which I have yet to detect any problems), I have: 70-persistent-cd.rules 70-persistent-net.rules 80-net-name-slot.rules kino.rules local.rules Only media-video/kino actually claims one of those files. If I missed an elog message somewhere, I'm ready for my flogging. :) Rich
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 16:35, Rich Freeman wrote: On Fri, Mar 29, 2013 at 9:44 AM, Samuli Suominen ssuomi...@gentoo.org wrote: What do you have there? We cover bunch of those in pkg_postinst of udev already. After a bunch of cleanup (after which I have yet to detect any problems), I have: 70-persistent-cd.rules 70-persistent-net.rules 80-net-name-slot.rules kino.rules local.rules Only media-video/kino actually claims one of those files. If I missed an elog message somewhere, I'm ready for my flogging. :) Rich I fixed kino but I didn't revision bump for it. Waiting for something bigger to revbump it. If you re-emerge kino, the rule will move to /lib/udev/rules.d. Those 70-* and 80-* are in udev pkg_postinst, this news item, everywhere... can all 3 be deleted if you haven't modified them yourself. So that leaves one... local.rules... dunno about that. I'm curious. - Samuli
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 10:45 AM, Samuli Suominen ssuomi...@gentoo.org wrote: Those 70-* and 80-* are in udev pkg_postinst, this news item, everywhere... can all 3 be deleted if you haven't modified them yourself. So that leaves one... local.rules... dunno about that. I'm curious. Excellent, sounds good then. The local rules are exactly what it sounds like - my own stuff. Some of what it does is obsolete now. It maps persistent symlinks to two pl2303 rs232 usb interfaces (which I believe is a solved problem now). It maps persistent symlinks to a few video capture devices (not a solved problem afaik). It assigns firewire ports to the video group (no idea if that is now in the standard rules). Rich
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29 March 2013 16:21, Nuno J. Silva (aka njsg) nunojsi...@ist.utl.ptwrote: On 2013-03-29, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Okay let me re-qualify the statement: If my desktop only has one Ethernet interface, and I don't mess up with it in userspace at all, no matter how many kernel changes happen, it'll always be eth0. Yes, the previous persistent rules for udev would have messed that one up when e1000e got split, or if you switched between the Broadcom-provided driver to the kernel one or vice-versa. The deathforce drivers come in mind as well. IMHO this is really relevant. It is annoying seeing how many people go oh you *must not* use the old scheme, because it won't work. The new naming scheme does *not* prevent you from using eth0, users should really just be told they can *disable* udev rules (and told how to do it) if they are happy with the kernel name of their sole network card, instead of being told that they *must* upgrade to the new rules. The messages so far seem to imply that you can't have eth0. You *can*, but udev won't be able to do anything if the device appears as something else and there's already another eth0. If you don't already have eth0, the udev rules *will* work, even if your card is named in the eth namespace. The *only* thing that breaks is renaming network devices to names that are already in use inside the kernel namespaces. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/ I sort of agree here. The news item is rather scary for people maintaining remote boxes. Couldn't we just preserve the old behavior with an opt-in for people who want to use this new feature? Or am I reading the message wrong? In my mind, the message says either remove 70-* and setup 80-* or your system will end up broken. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 12:40 PM, Markos Chandras hwoar...@gentoo.org wrote: In my mind, the message says either remove 70-* and setup 80-* or your system will end up broken. The other bit is that modifying symlinks in /etc/init.d is only mentioned in passing. That is a VERY important step unless your new name happens to be the same as your old one, otherwise on the next boot the system will not have a working network interface, which will hamper efforts to fix for casual/new users, and cause real trouble for those doing remote administration (though anybody doing anything serious on a remotely-administered box should have some kind of console-level access outside of the OS - like serial console or iLO/etc support). Rich
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/13 18:21, Nuno J. Silva (aka njsg) wrote: On 2013-03-29, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: Diego Elio Pettenò schrieb: If my desktop only has one Ethernet interface, no matter how many kernel changes happen, it'll always be eth0. That was not true with the old persistent naming. One example which we encountered in #gentoo IRC was the split between e1000 and e1000e drivers which caused interfaces to change names. Okay let me re-qualify the statement: If my desktop only has one Ethernet interface, and I don't mess up with it in userspace at all, no matter how many kernel changes happen, it'll always be eth0. Yes, the previous persistent rules for udev would have messed that one up when e1000e got split, or if you switched between the Broadcom-provided driver to the kernel one or vice-versa. The deathforce drivers come in mind as well. IMHO this is really relevant. It is annoying seeing how many people go oh you *must not* use the old scheme, because it won't work. The new naming scheme does *not* prevent you from using eth0, users should really just be told they can *disable* udev rules (and told how to do it) if they are happy with the kernel name of their sole network card, instead of being told that they *must* upgrade to the new rules. The messages so far seem to imply that you can't have eth0. You *can*, but udev won't be able to do anything if the device appears as something else and there's already another eth0. If you don't already have eth0, the udev rules *will* work, even if your card is named in the eth namespace. The *only* thing that breaks is renaming network devices to names that are already in use inside the kernel namespaces. I think you may have not seen the latest version, it says for eg. If you only have one interface card, you don't necessarily have much use for this feature as the name almost always stays at eth0, you can easily disable it using forementioned methods. After first listing 3 different ways of disabling the new names earlier. http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob_plain;f=2013/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt;hb=HEAD But I'd prefer not to lead people to the path of renaming into namespace already taken... that can lead to issues. It sounds almost as hackish as the script that frees the whole namespace by using temporary names: https://bugs.gentoo.org/attachment.cgi?id=336774 Still trying to decipher people if there is more to adjust in the news though, it doesn't have to be frozen as is, if you have better wording, please provide a patch against the current. Thanks :) - Samuli
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I don't have enough time to go through the rest of this thread, but if the first sentence hasn't been adjusted yet: On 29/03/13 08:20 AM, Samuli Suominen wrote: If you still have network interface renaming rules in /etc/udev/rules.d, like 70-persistent-net.rules, you will need to modify or remove them. Might I recommend at least a little bit of context before going right into you have to remove these rules? IE - if a user wants to keep the old mac-based rules they already have, can't they? 80-*.rules doesn't override that now, does it? I'd recommend: As of version 197, udev now provides predictable interface renaming based directly on [hardware addresses and whatever other info]. The old MAC-based relabelling in prior udev versions has been removed, and it is highly recommended to migrate to the new version. ...as the first paragraph. Then follow with the rest. Friendly? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlFV6WMACgkQ2ugaI38ACPAMAAD/aJC64ISmRlspep2FU3vuBHuB o+tEueMLIrNnHgNtC7sA/0JIl9H5gbX6talhmPkxKLbMdcaAAWvB4osN1pgWC45H =XH7f -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 29/03/2013 20:20, Ian Stakenvicius wrote: Might I recommend at least a little bit of context before going right into you have to remove these rules? IE - if a user wants to keep the old mac-based rules they already have, can't they? 80-*.rules doesn't override that now, does it? It doesn't override it _but_ if you were using the old eth* names, it will drop support for the in-place renaming (i.e. the ability to swap eth0 and eth1). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 01:38:03PM -0400, Rich Freeman wrote On Fri, Mar 29, 2013 at 12:40 PM, Markos Chandras hwoar...@gentoo.org wrote: In my mind, the message says either remove 70-* and setup 80-* or your system will end up broken. The other bit is that modifying symlinks in /etc/init.d is only mentioned in passing. That is a VERY important step unless your new name happens to be the same as your old one, otherwise on the next boot the system will not have a working network interface, which will hamper efforts to fix for casual/new users, and cause real trouble for those doing remote administration (though anybody doing anything serious on a remotely-administered box should have some kind of console-level access outside of the OS - like serial console or iLO/etc support). That's only the beginning for the necessary changes. I'm running mdev on this machine, so it won't affect me, but here goes... [d531][root][~] grep -rl eth[0-9] /etc/* /etc/conf.d/net /etc/conf.d/network /etc/conf.d/netmount /etc/dosemu/dosemu.conf /etc/hibernate/common.conf /etc/rc.conf I've eliminated some specific stuff that only I do. * /etc/conf.d/net Is going to have to be modified by users. * I believe /etc/conf.d/network is a doc file for /etc/conf.d/net. * /etc/conf.d/netmount Who changes that? * /etc/dosemu/dosemu.conf It's an app, but may require changes. * /etc/hibernate/common.conf It's an app, but may require changes. * /etc/rc.conf Is going to have to be modified by users. Fun for users, and app upstreams. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
