Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote: On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote: On 2013-04-05 4:11 PM, William Hubbs willi...@gentoo.org wrote: On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote: Just dealing with one server and my Linux router, they've been updated to sys-fs/udev-200 and are both still using the same /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year, which was working with udev-171. Do you have your network interface drivers built into the kernel or are they modules? I'm very interested in the significance of this question... My server is module free, so all drivers are built into the kernel. The significance is that the kernel determines the eth* name order. Right now, you are lucky in that the order is what you think it should be, but if something changes in the kernel causing your cards to be initialized in a different order, you will not be allowed to swap them around in the eth* name space, e.g. eth1 can't become eth0 or visa versa. That is why it is recommended that you use something like net0, net1, etc for your interface names. Thanks for your reply. After 10 years of eth* it's going to be hard to make a change until the kernel does this, also. Bruce -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 04/08/2013 11:04 AM, Bruce Hill wrote: On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote: On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote: On 2013-04-05 4:11 PM, William Hubbs willi...@gentoo.org wrote: On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote: Just dealing with one server and my Linux router, they've been updated to sys-fs/udev-200 and are both still using the same /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year, which was working with udev-171. Do you have your network interface drivers built into the kernel or are they modules? I'm very interested in the significance of this question... My server is module free, so all drivers are built into the kernel. The significance is that the kernel determines the eth* name order. Right now, you are lucky in that the order is what you think it should be, but if something changes in the kernel causing your cards to be initialized in a different order, you will not be allowed to swap them around in the eth* name space, e.g. eth1 can't become eth0 or visa versa. That is why it is recommended that you use something like net0, net1, etc for your interface names. Thanks for your reply. After 10 years of eth* it's going to be hard to make a change until the kernel does this, also. No kidding. There's almost 30 years' documentation out there that assumes 'eth0' is the interface you care about, except in cases where you care about 'eth0' and 'eth1'. As far as the kernel namespace issue...there needs to be a different namespace between what the kernel defines and what udev can control; at the moment, if you define your own NIC names (say, wan1, wan2), there's a chance that a kernel driver will stomp on it if you start using a card that has a driver that likes that numbering scheme. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote:
The significance is that the kernel determines the eth* name order.
Right now, you are lucky in that the order is what you think it should
be, but if something changes in the kernel causing your cards to be
initialized in a different order, you will not be allowed to swap them
around in the eth* name space, e.g. eth1 can't become eth0 or visa
versa.
That is why it is recommended that you use something like net0, net1,
etc for your interface names.
William
This doesn't seem consistent with my experience. The reason that I edited the
70-persistent-net.rules file to begin with is to make the NICs whatever eth* I
wanted, regardless of the order the kernel loaded them. Since the modules are
built-in, and both NICs use the same module, I think this won't change.
The server has two built-in NICs. One is being used to connect it to the
switch, and the other is not in use (backup). One has ID 1 and the other ID 2.
The kernel was loading the one with the higher MAC address first, and the
lower MAC address second. The lower MAC number is the one with the stamp ID 1
on the back of the server, so I edited the rules file to load it always as
eth1 so my /etc/conf.d/net can use static IPs (like everything wired on the
LAN); because the ethernet cable is connected from ID 1 to the switch. Thus:
server ~ # dmesg | grep -i eth
[ 11.691830] tg3 :03:00.0: eth0: Tigon3 [partno(BCM95721) rev 4101] (PCI
Express) MAC address 00:d0:68:0b:87:67
[ 11.691985] tg3 :03:00.0: eth0: attached PHY is 5750 (10/100/1000Base-T
Ethernet) (WireSpeed[1], EEE[0])
[ 11.692192] tg3 :03:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1]
TSOcap[1]
[ 11.692340] tg3 :03:00.0: eth0: dma_rwctrl[7618] dma_mask[64-bit]
[ 11.699283] tg3 :02:00.0: eth1: Tigon3 [partno(BCM95721) rev 4101] (PCI
Express) MAC address 00:d0:68:0b:87:66
[ 11.699439] tg3 :02:00.0: eth1: attached PHY is 5750 (10/100/1000Base-T
Ethernet) (WireSpeed[1], EEE[0])
[ 11.699591] tg3 :02:00.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0]
TSOcap[1]
[ 11.699738] tg3 :02:00.0: eth1: dma_rwctrl[7618] dma_mask[64-bit]
[ 82.703869] tg3 :02:00.0: eth1: Link is up at 1000 Mbps, full duplex
[ 82.703875] tg3 :02:00.0: eth1: Flow control is off for TX and off for RX
server ~ # cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:d0:68:0b:87:66, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth1
# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:d0:68:0b:87:67, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth0
server ~ # ip addr show
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:d0:68:0b:87:67 brd ff:ff:ff:ff:ff:ff
3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:d0:68:0b:87:66 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.3/24 brd 192.168.100.255 scope global eth1
The Linux router has 3 NICs in use. Two of them are identical Intel cards. It
controls 3 networks, and there's a backup NIC of the same brand. So it's
important for me to know the assignment of them, and again,
70-persistent-net.rules allows me to keep the ordered according to MAC
address:
router log # zgrep -i eth* kern.log-20130326.gz
Mar 25 18:31:47 router kernel: [1.434939] pata_amd :00:06.0: setting
latency timer to 64
Mar 25 18:31:47 router kernel: [1.436360] e1000e: Intel(R) PRO/1000 Network
Driver - 1.9.5-k
Mar 25 18:31:47 router kernel: [1.437229] e1000e :02:00.0:
(unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic
conservative mode
Mar 25 18:31:47 router kernel: [1.540889] e1000e :02:00.0: eth0: (PCI
Express:2.5GT/s:Width x1) 68:05:ca:03:05:50
Mar 25 18:31:47 router kernel: [1.541039] e1000e :02:00.0: eth0:
Intel(R) PRO/1000 Network Connection
Mar 25 18:31:47 router kernel: [1.541185] e1000e :02:00.0: eth0: MAC:
3, PHY: 8, PBA No: E46981-007
Mar 25 18:31:47 router kernel: [1.542263] e1000e :03:00.0:
(unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic
conservative mode
Mar 25 18:31:47 router kernel: [1.644050] e1000e :03:00.0: eth1: (PCI
Express:2.5GT/s:Width x1) 68:05:ca:03:05:5d
Mar 25 18:31:47 router kernel: [1.644196] e1000e :03:00.0: eth1:
Intel(R) PRO/1000 Network Connection
Mar 25 18:31:47 router
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 7 Apr 2013 03:06:30 + (UTC), Grant Edwards wrote: Wha? I swear I was told that you could not reliably name the iterfaces eth[0-n] using udev rules (which is what I've always done without problems) because of race conditions. So I changed over to net[0-n] on one machine, and was planning on doing so on the others soon. Can we still use udev rules to name interfaces eth[0-n] or not? Yes, just as before. And just as before, you cannot rely on it working every time. -- Neil Bothwick Linuxgeek How do i find the model of my card? Serena[T] your nick is misleading, seriously signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 7 Apr 2013 00:34:03 -0400, Walter Dnes wrote: Now I only had to figure out how to rename eth[0-9]+ to the custom naming scheme when using mdev. ***UDEV*** has broken using eth[0-9]. mdev works just fine, thank you. udev has broken nothing, it is avoiding the breakage caused by a fundamentally flawed renaming procedure. Or does mdev have some magic for for renaming eth0 to eth1 while eth1 already exists? -- Neil Bothwick Having children will turn you into your parents. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Apr 7, 2013 5:59 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 7 Apr 2013 00:34:03 -0400, Walter Dnes wrote: Now I only had to figure out how to rename eth[0-9]+ to the custom naming scheme when using mdev. ***UDEV*** has broken using eth[0-9]. mdev works just fine, thank you. udev has broken nothing, it is avoiding the breakage caused by a fundamentally flawed renaming procedure. Or does mdev have some magic for for renaming eth0 to eth1 while eth1 already exists? Broken or not is totally depending on the eye of the beholder. Server SysAdmins *sometimes* need to reboot, and if the name suddenly changes, that's hell on earth for us. AFAICT, prior to udev-200, once an interface got assigned an ethX moniker, it just won't change name unless there's a hardware change. At least, that's my experience so far. Rgds, --
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 7 Apr 2013 22:26:52 +0700, Pandu Poluan wrote: udev has broken nothing, it is avoiding the breakage caused by a fundamentally flawed renaming procedure. Or does mdev have some magic for for renaming eth0 to eth1 while eth1 already exists? Broken or not is totally depending on the eye of the beholder. Server SysAdmins *sometimes* need to reboot, and if the name suddenly changes, that's hell on earth for us. AFAICT, prior to udev-200, once an interface got assigned an ethX moniker, it just won't change name unless there's a hardware change. At least, that's my experience so far. But that isn't guaranteed. Basically, renaming within the eth namespace has always had the potential for breakage, whether it worked for you or not. The fact that for 99% of the time it didn't break doesn't remove that potential, and a server with multiple NICs is more likely to be affected than a laptop. Also, if you believe the breakage won't apply to you, there is nothing to stop you continuing with your old rules, in fact that is exactly what udev does if you don't remove them yourself. -- Neil Bothwick Many husbands go broke on the money their wives save on sales. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote: On 2013-04-05 4:11 PM, William Hubbs willi...@gentoo.org wrote: On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote: Just dealing with one server and my Linux router, they've been updated to sys-fs/udev-200 and are both still using the same /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year, which was working with udev-171. Do you have your network interface drivers built into the kernel or are they modules? I'm very interested in the significance of this question... My server is module free, so all drivers are built into the kernel. The significance is that the kernel determines the eth* name order. Right now, you are lucky in that the order is what you think it should be, but if something changes in the kernel causing your cards to be initialized in a different order, you will not be allowed to swap them around in the eth* name space, e.g. eth1 can't become eth0 or visa versa. That is why it is recommended that you use something like net0, net1, etc for your interface names. William pgpLBZjeEifdp.pgp Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-07 4:09 PM, William Hubbs willi...@gentoo.org wrote: On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote: On 2013-04-05 4:11 PM, William Hubbs willi...@gentoo.org wrote: Do you have your network interface drivers built into the kernel or are they modules? I'm very interested in the significance of this question... My server is module free, so all drivers are built into the kernel. The significance is that the kernel determines the eth* name order. Right now, you are lucky in that the order is what you think it should be, but if something changes in the kernel causing your cards to be initialized in a different order, you will not be allowed to swap them around in the eth* name space, e.g. eth1 can't become eth0 or visa versa. That is why it is recommended that you use something like net0, net1, etc for your interface names. Wow... that is actually what I was thinking it meant, but wasn't sure... Thanks for the validation!
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote: * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS* * drivers are built as modules, not built-in into the kernel * is it possible to set things up so that the network driver modules do not load automatically at bootup? * have a script in /etc/local.d/ (or wherever) modprobe the drivers in the desired order I can see complications involving services that depend on net (e.g. sshd), but in general, would it work reliably? What happens if one of the modules fails to load for any reason? If you need persistent device names, set up rules to give them, but use names outside of the kernel namespace to avoid the problems that udev is trying to avoid with its new naming rules. -- Neil Bothwick Where do you think you're going today? signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Saturday 06 Apr 2013 09:43:28 Neil Bothwick wrote: On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote: * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS* * drivers are built as modules, not built-in into the kernel * is it possible to set things up so that the network driver modules do not load automatically at bootup? * have a script in /etc/local.d/ (or wherever) modprobe the drivers in the desired order I can see complications involving services that depend on net (e.g. sshd), but in general, would it work reliably? What happens if one of the modules fails to load for any reason? If you need persistent device names, set up rules to give them, but use names outside of the kernel namespace to avoid the problems that udev is trying to avoid with its new naming rules. Answering Walter's question - from my experience on at least two boxen that I've rebooted since udev 200: My ethernet cards which had their driver built in the kernel were renamed by udev to the enp_something predictable name. The wireless cards that I had them built as modules remained the same as before; e.g. wlan0. I only have one wireless card in each machine so I don't know if the naming will get mixed up, if I had more than one and the kernel decided to modprobe them in a different order. I expect that it would rename them as it would do before udev-200, in which case a 70-net-names.rules would bring things back to even keel. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Apr 6, 2013 3:44 PM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote: * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS* * drivers are built as modules, not built-in into the kernel * is it possible to set things up so that the network driver modules do not load automatically at bootup? * have a script in /etc/local.d/ (or wherever) modprobe the drivers in the desired order I can see complications involving services that depend on net (e.g. sshd), but in general, would it work reliably? What happens if one of the modules fails to load for any reason? If you need persistent device names, set up rules to give them, but use names outside of the kernel namespace to avoid kk problems that udev is trying to avoid with its new naming rules.ooh Ahhh... I think now I understand... So. Here's my summarization of the situation: * The ethX naming can change, i.e., the interfaces can get out of order * So, to fix this, udev decided to use the physical attachment points of the NIC in driving a persistent name, a name that will be identical across boots as long as there is no hardware change * In doing so, it also frees the 'traditional' ethX names to be used * If one wants, one can still 'rename' the NICs to the 'traditional' names using the 70-*.rules script * Doing so (specifying the NICs' names using the 70-*r.rules script) will also disable the new 'persistent naming' system -- for the NICs specified in the 70-*r.rules file * Therefore, users that will be impacted are those that upgraded udev but doesn't have the 70-*r.rules, for udev will then assign new names for the NICs * For these users, specifying the netsomething switch for the kernel (sorry, forgot the complete switch) will disable the new naming system So, have I gotten everything correctly? CMIIW, please. Rgds, --
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sat, 6 Apr 2013 19:11:46 +0700 Pandu Poluan pa...@poluan.info wrote: On Apr 6, 2013 3:44 PM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote: * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS* * drivers are built as modules, not built-in into the kernel * is it possible to set things up so that the network driver modules do not load automatically at bootup? * have a script in /etc/local.d/ (or wherever) modprobe the drivers in the desired order I can see complications involving services that depend on net (e.g. sshd), but in general, would it work reliably? What happens if one of the modules fails to load for any reason? If you need persistent device names, set up rules to give them, but use names outside of the kernel namespace to avoid kk problems that udev is trying to avoid with its new naming rules.ooh Ahhh... I think now I understand... So. Here's my summarization of the situation: * The ethX naming can change, i.e., the interfaces can get out of order * So, to fix this, udev decided to use the physical attachment points of the NIC in driving a persistent name, a name that will be identical across boots as long as there is no hardware change There are also other ways such as using the mac address (disabled by default). * In doing so, it also frees the 'traditional' ethX names to be used No. The eth[0-9]+ namespace is not free, it has always been used by the linux kernel, and will stay so. * If one wants, one can still 'rename' the NICs to the 'traditional' names using the 70-*.rules script * Doing so (specifying the NICs' names using the 70-*r.rules script) will also disable the new 'persistent naming' system -- for the NICs specified in the 70-*r.rules file * Therefore, users that will be impacted are those that upgraded udev but doesn't have the 70-*r.rules, for udev will then assign new names for the NICs * For these users, specifying the netsomething switch for the kernel (sorry, forgot the complete switch) will disable the new naming system So, have I gotten everything correctly? Almost, except you should not specify a name that is also eth[0-9]+ (what you called 'traditional' name), since it can cause a race condition where the kernel and udev fight for the name. While it used to be the case (i.e. udev-197) that udev tries to handle the race condition, the devs has decided to remove those code. Regards, Kerwin. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-06 8:31 AM, kwk...@hkbn.net kwk...@hkbn.net wrote: Almost, except you should not specify a name that is also eth[0-9]+ (what you called 'traditional' name), since it can cause a race condition where the kernel and udev fight for the name. While it used to be the case (i.e. udev-197) that udev tries to handle the race condition, the devs has decided to remove those code. Ok, thanks, I *think* I've got a handle on this now (sorry for being so dense)... So, other than userland scripts that I created myself and know where they live, where do I search for any files/scripts created/generated/maintained by the system, for references to eth0/1 to change to net0/1? Is it just /etc/conf.d?
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-05 4:11 PM, William Hubbs willi...@gentoo.org wrote: On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote: Just dealing with one server and my Linux router, they've been updated to sys-fs/udev-200 and are both still using the same /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year, which was working with udev-171. Do you have your network interface drivers built into the kernel or are they modules? I'm very interested in the significance of this question... My server is module free, so all drivers are built into the kernel. Does this provide for another option and/or make things easier?
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sat, 06 Apr 2013 10:22:49 -0400, Tanstaafl wrote: So, other than userland scripts that I created myself and know where they live, where do I search for any files/scripts created/generated/maintained by the system, for references to eth0/1 to change to net0/1? Is it just /etc/conf.d? /etc/udev/rules.d Or grep -r 'eth[0-9]' /etc. -- Neil Bothwick Sure, we just route the main sensor through Data's cat. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Apr 6, 2013 7:32 PM, kwk...@hkbn.net wrote: On Sat, 6 Apr 2013 19:11:46 +0700 Pandu Poluan pa...@poluan.info wrote: On Apr 6, 2013 3:44 PM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote: * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS* * drivers are built as modules, not built-in into the kernel * is it possible to set things up so that the network driver modules do not load automatically at bootup? * have a script in /etc/local.d/ (or wherever) modprobe the drivers in the desired order I can see complications involving services that depend on net (e.g. sshd), but in general, would it work reliably? What happens if one of the modules fails to load for any reason? If you need persistent device names, set up rules to give them, but use names outside of the kernel namespace to avoid kk problems that udev is trying to avoid with its new naming rules.ooh Ahhh... I think now I understand... So. Here's my summarization of the situation: * The ethX naming can change, i.e., the interfaces can get out of order * So, to fix this, udev decided to use the physical attachment points of the NIC in driving a persistent name, a name that will be identical across boots as long as there is no hardware change There are also other ways such as using the mac address (disabled by default). * In doing so, it also frees the 'traditional' ethX names to be used No. The eth[0-9]+ namespace is not free, it has always been used by the linux kernel, and will stay so. * If one wants, one can still 'rename' the NICs to the 'traditional' names using the 70-*.rules script * Doing so (specifying the NICs' names using the 70-*r.rules script) will also disable the new 'persistent naming' system -- for the NICs specified in the 70-*r.rules file * Therefore, users that will be impacted are those that upgraded udev but doesn't have the 70-*r.rules, for udev will then assign new names for the NICs * For these users, specifying the netsomething switch for the kernel (sorry, forgot the complete switch) will disable the new naming system So, have I gotten everything correctly? Almost, except you should not specify a name that is also eth[0-9]+ (what you called 'traditional' name), since it can cause a race condition where the kernel and udev fight for the name. While it used to be the case (i.e. udev-197) that udev tries to handle the race condition, the devs has decided to remove those code. Regards, Kerwin. Ah, thanks for the clarification! :-) So, from now on, for safety I'm going to use a custom naming scheme, like lan[0-9]+ or wan[0-9]+ or wifi[0-9]+, anything that won't collide with kernel names of eth[0-9]+ Now I only had to figure out how to rename eth[0-9]+ to the custom naming scheme when using mdev. Rgds, --
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-06 10:40 AM, Neil Bothwick n...@digimed.co.uk wrote: On Sat, 06 Apr 2013 10:22:49 -0400, Tanstaafl wrote: So, other than userland scripts that I created myself and know where they live, where do I search for any files/scripts created/generated/maintained by the system, for references to eth0/1 to change to net0/1? Is it just /etc/conf.d? /etc/udev/rules.d Or grep -r 'eth[0-9]' /etc. Perfect, thanks Neil...
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sat, Apr 06, 2013 at 07:11:46PM +0700, Pandu Poluan wrote:
Ahhh... I think now I understand...
So. Here's my summarization of the situation:
* The ethX naming can change, i.e., the interfaces can get out of order
* So, to fix this, udev decided to use the physical attachment points of
the NIC in driving a persistent name, a name that will be identical across
boots as long as there is no hardware change
* In doing so, it also frees the 'traditional' ethX names to be used
* If one wants, one can still 'rename' the NICs to the 'traditional' names
using the 70-*.rules script
* Doing so (specifying the NICs' names using the 70-*r.rules script) will
also disable the new 'persistent naming' system -- for the NICs specified
in the 70-*r.rules file
* Therefore, users that will be impacted are those that upgraded udev but
doesn't have the 70-*r.rules, for udev will then assign new names for the
NICs
* For these users, specifying the netsomething switch for the kernel
(sorry, forgot the complete switch) will disable the new naming system
So, have I gotten everything correctly?
Works for me...
mingdao@router ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==68:05:ca:03:05:5d, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth0
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==68:05:ca:03:05:50, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth1
# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==f4:6d:04:e8:1d:d9, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth2
mingdao@router ~ $ ip addr show
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN
link/ether f2:58:cb:48:72:b3 brd ff:ff:ff:ff:ff:ff
3: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 68:05:ca:03:05:50 brd ff:ff:ff:ff:ff:ff
inet 192.168.54.1/24 brd 192.168.54.255 scope global eth0
4: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 68:05:ca:03:05:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1
5: eth2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether f4:6d:04:e8:1d:d9 brd ff:ff:ff:ff:ff:ff
inet public IP brd munged scope global eth2
If these NICs don't get assigned correctly, this whole LAN fails.
--
Happy Penguin Computers ')
126 Fenco Drive ( \
Tupelo, MS 38801 ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-06, Pandu Poluan pa...@poluan.info wrote: Ahhh... I think now I understand... So. Here's my summarization of the situation: * The ethX naming can change, i.e., the interfaces can get out of order * So, to fix this, udev decided to use the physical attachment points of the NIC in driving a persistent name, a name that will be identical across boots as long as there is no hardware change * In doing so, it also frees the 'traditional' ethX names to be used * If one wants, one can still 'rename' the NICs to the 'traditional' names using the 70-*.rules script Wha? I swear I was told that you could not reliably name the iterfaces eth[0-n] using udev rules (which is what I've always done without problems) because of race conditions. So I changed over to net[0-n] on one machine, and was planning on doing so on the others soon. Can we still use udev rules to name interfaces eth[0-n] or not? -- Grant Edwards grant.b.edwardsYow! I've got an IDEA!! at Why don't I STARE at you gmail.comso HARD, you forget your SOCIAL SECURITY NUMBER!!
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 04/06/2013 11:06 PM, Grant Edwards wrote: On 2013-04-06, Pandu Poluan pa...@poluan.info wrote: Ahhh... I think now I understand... So. Here's my summarization of the situation: * The ethX naming can change, i.e., the interfaces can get out of order * So, to fix this, udev decided to use the physical attachment points of the NIC in driving a persistent name, a name that will be identical across boots as long as there is no hardware change * In doing so, it also frees the 'traditional' ethX names to be used * If one wants, one can still 'rename' the NICs to the 'traditional' names using the 70-*.rules script Wha? I swear I was told that you could not reliably name the iterfaces eth[0-n] using udev rules (which is what I've always done without problems) because of race conditions. So I changed over to net[0-n] on one machine, and was planning on doing so on the others soon. Can we still use udev rules to name interfaces eth[0-n] or not? If and only if there is no device named ethN when you go to name a device ethN. That's what's meant by 'reliably'. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sat, Apr 06, 2013 at 09:46:13PM +0700, Pandu Poluan wrote Ah, thanks for the clarification! :-) So, from now on, for safety I'm going to use a custom naming scheme, like lan[0-9]+ or wan[0-9]+ or wifi[0-9]+, anything that won't collide with kernel names of eth[0-9]+ Now I only had to figure out how to rename eth[0-9]+ to the custom naming scheme when using mdev. ***UDEV*** has broken using eth[0-9]. mdev works just fine, thank you. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-03 6:28 PM, Mick michaelkintz...@gmail.com wrote:
On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote:
Therefore, all's well that's still working! And AFAIR, on at least 2 of
those machines, the 70-persistent-net.rules was never something I did
manually.
Right, it used to be auto-generated by udev scripts. With udev-200 you are
meant to remove it along with any other files from your /etc/udev/rules.d/
If you left them there and their syntax is still valid, then udev will parse
them and do as is told.
Ok, so...
I just realized that my current/existing 70-persistent-net.rules syntax
is different from the 'old format' referenced in the udev upgrade news
item. I have:
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:e0:81:54:9c:8b, KERNEL==eth*,
NAME=eth1
# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:e0:81:54:9c:8a, KERNEL==eth*,
NAME=eth0
Note the 'DRIVERS==' and 'KERNEL==' items that are not showing in the
news item example for the old format, as well as the LACK of the
'ACTION==' item... is this dependent on the interface type? Or is mine
'wrong' (and just has been working by accident all these years)?
So, now I'm even more confused.
If I just want to totally disable the new behavior and keep the old, I
know I just add 'net.ifnames=0' on the kernel command-line, but...
Do I just rename the above file to something like
'70-my-net-names.rules', keeping the content the same?
Or do I need to edit the lines? And if so, to what? Do I remove the
'DRIVERS==' and 'KERNEL==' items and add the 'ACTION==' item?
Do I change the eth0 to net0 (and create the symlink and update
rc-update as discussed earlier)?
crap-crud...
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Thu, Apr 04, 2013 at 09:07:00AM -0400, Tanstaafl wrote: On 2013-04-04 5:13 AM, Alan McKinnon alan.mckin...@gmail.com wrote: I gets so bad that people are starting to make shit up to be worried about, instead of just reading the simple document that is right in front of their eyes that already fully and completely answers the question at hand But Alan, haven't you read the recent (past couple of DAYS) emails in this very thread from people who followed the current 'simple document' you refer to and it did not work as advertised? I don't think these people are making this stuff up - are you saying you do? Not to mention the fact that this final/current seemingly complete document was way, way too late for the many people who ended up with totally broken systems, and *that* is what caused all of the 'hysteria and mob-think' you so condescendingly speak of. It is these reports that is causing me all kinds of fear/trepidation at this seemingly simple/benign update (as you seem to believe it is). So, again, I would really, really like a very simple answer as to the *best* way to retain the old way that is least likely to cause problems down the road (ie, if/when udev is subsumed by systemd). Currently I count 3 different ways. You are right, there are several different ways to disable udev's predictable network interface names: 1) add net.ifnames=0 to the kernel command line in your boot loader configuration. 2) use any of the methods listed on the upstream wiki [1] under I don't like this, how do I disable this? None of those should cause problems later. William [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames pgpEMxf4Me5Ht.pgp Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
But what confuses me about that linked page is that from what I've heard from others here, option 1 - which is the option I think I'd prefer - requires more than just symlinking 80-net-name-slot.rules to /dev/null...? Apparently you should also create your own 70-my-net-names.rules - but I've heard many people claim they used ethX names instead of netX names, so... again... should I just rename my file to 70-my-net-names.rules and leave the contents alone? Still confused/concerned about the differences in my current rules (items in mine that aren't in the examples)... On 2013-04-05 12:17 PM, William Hubbs willi...@gentoo.org wrote: You are right, there are several different ways to disable udev's predictable network interface names: 1) add net.ifnames=0 to the kernel command line in your boot loader configuration. 2) use any of the methods listed on the upstream wiki [1] under I don't like this, how do I disable this? None of those should cause problems later. William [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, Apr 05, 2013 at 01:32:23PM -0400, Tanstaafl wrote: But what confuses me about that linked page is that from what I've heard from others here, option 1 - which is the option I think I'd prefer - requires more than just symlinking 80-net-name-slot.rules to /dev/null...? Apparently you should also create your own 70-my-net-names.rules - but I've heard many people claim they used ethX names instead of netX names, so... again... should I just rename my file to 70-my-net-names.rules and leave the contents alone? symlinking /etc/udev/rules.d/80-net-name-slot.rules to /dev/null does the same thing as adding net.ifnames=0 to your kernel command line, so choose one or the other of these. Neither of these is needed if you want to have your own names, because naming the interfaces yourself in /etc/uev/70-net-names.rules or whatever you call the file overrides udev's predictable names. If people are using ethx names and getting away with it it is probably because they are loading the drivers as modules, or by chance the kernel is initializing the cards in the order they expect. There is no guarantee that will stay consistent. I recommend using netx names. Does that clear it up? William pgpoQ1XV970pI.pgp Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-05 2:41 PM, William Hubbs willi...@gentoo.org wrote:
On Fri, Apr 05, 2013 at 01:32:23PM -0400, Tanstaafl wrote:
But what confuses me about that linked page is that from what I've heard
from others here, option 1 - which is the option I think I'd prefer -
requires more than just symlinking 80-net-name-slot.rules to
/dev/null...? Apparently you should also create your own
70-my-net-names.rules - but I've heard many people claim they used ethX
names instead of netX names, so... again... should I just rename my file
to 70-my-net-names.rules and leave the contents alone?
symlinking /etc/udev/rules.d/80-net-name-slot.rules to /dev/null does
the same thing as adding net.ifnames=0 to your kernel command line, so
choose one or the other of these.
Neither of these is needed if you want to have your own names,
because naming the interfaces yourself in /etc/uev/70-net-names.rules or
whatever you call the file overrides udev's predictable names.
If people are using ethx names and getting away with it it is probably
because they are loading the drivers as modules, or by chance the kernel
is initializing the cards in the order they expect. There is no
guarantee that will stay consistent.
I recommend using netx names.
Does that clear it up?
Well, to a point (as to whether I use netX or ethX)...
I'd still like to know why the contents of my current rules file differs
so much from the examples I've seen... ie, the two extra items that are
in mine ('DRIVERS==' and 'KERNEL=='), and the missing one
('ACTION==')... and whether or not I should include these if I decide to
go with my own rules file...
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, Apr 05, 2013 at 01:41:28PM -0500, William Hubbs wrote: On Fri, Apr 05, 2013 at 01:32:23PM -0400, Tanstaafl wrote: But what confuses me about that linked page is that from what I've heard from others here, option 1 - which is the option I think I'd prefer - requires more than just symlinking 80-net-name-slot.rules to /dev/null...? Apparently you should also create your own 70-my-net-names.rules - but I've heard many people claim they used ethX names instead of netX names, so... again... should I just rename my file to 70-my-net-names.rules and leave the contents alone? symlinking /etc/udev/rules.d/80-net-name-slot.rules to /dev/null does the same thing as adding net.ifnames=0 to your kernel command line, so choose one or the other of these. Neither of these is needed if you want to have your own names, because naming the interfaces yourself in /etc/uev/70-net-names.rules or whatever you call the file overrides udev's predictable names. If people are using ethx names and getting away with it it is probably because they are loading the drivers as modules, or by chance the kernel is initializing the cards in the order they expect. There is no guarantee that will stay consistent. There is one more situation where you would get away with eth0, and that is if you just have one network card. But, as soon as you add another card, there is no guarantee that eth0 will refer to the card you expect it to refer to. I recommend using netx names. Does that clear it up? William pgpS86373M0lW.pgp Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, Apr 05, 2013 at 01:41:28PM -0500, William Hubbs wrote:
Neither of these is needed if you want to have your own names,
because naming the interfaces yourself in /etc/uev/70-net-names.rules or
whatever you call the file overrides udev's predictable names.
If people are using ethx names and getting away with it it is probably
because they are loading the drivers as modules, or by chance the kernel
is initializing the cards in the order they expect. There is no
guarantee that will stay consistent.
I recommend using netx names.
Does that clear it up?
William
Just dealing with one server and my Linux router, they've been updated to
sys-fs/udev-200 and are both still using the same
/etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
which was working with udev-171.
mingdao@server ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:d0:68:0b:87:66, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth1
# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:d0:68:0b:87:67, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth0
mingdao@router ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==68:05:ca:03:05:5d, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth0
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==68:05:ca:03:05:50, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth1
# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==f4:6d:04:e8:1d:d9, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth2
There is no log file or any indication of other than eth* for those NICs. And
neither those 2 or the other 3 Gentoo boxen on this LAN have ever had a
/etc/udev/rules.d/80-net-name-slot.rules file.
As stated before, I didn't want to upgrade past udev-171, but kerframil told
me it would work fine, don't worry, upgrade to stable. Though I did upgrade, I
didn't intend to reboot any of those boxen until I looked carefully. And then
March 29 we had a power outage for over an hour, none of the UPSes stood up
that long, but everything was the same when I started the machines again.
Amazed, as usual...
--
Happy Penguin Computers ')
126 Fenco Drive ( \
Tupelo, MS 38801 ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote: Just dealing with one server and my Linux router, they've been updated to sys-fs/udev-200 and are both still using the same /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year, which was working with udev-171. Do you have your network interface drivers built into the kernel or are they modules? William pgp4ceBTDmPux.pgp Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, Apr 05, 2013 at 02:58:02PM -0400, Tanstaafl wrote:
I'd still like to know why the contents of my current rules file differs
so much from the examples I've seen... ie, the two extra items that are
in mine ('DRIVERS==' and 'KERNEL=='), and the missing one
('ACTION==')... and whether or not I should include these if I decide to
go with my own rules file...
The first thing I would do if I were you is to test with one of the
examples (keeping my rules file somewhere as a backup), and if that
test works, I would go with it.
ACTION== is needed, but you may be able to get away without DRIVERS==
and KERNEL==.
William
pgpOnnyH1TJLN.pgp
Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, Apr 05, 2013 at 03:11:39PM -0500, William Hubbs wrote: On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote: Just dealing with one server and my Linux router, they've been updated to sys-fs/udev-200 and are both still using the same /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year, which was working with udev-171. Do you have your network interface drivers built into the kernel or are they modules? William All built in: mingdao@server ~ $ zgrep -i tigon /proc/config.gz CONFIG_TIGON3=y mingdao@router ~ $ zgrep -i e1000e /proc/config.gz CONFIG_E1000E=y mingdao@router ~ $ zgrep -i forcedeth /proc/config.gz CONFIG_FORCEDETH=y -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Fri, Apr 05, 2013 at 01:41:28PM -0500, William Hubbs wrote If people are using ethx names and getting away with it it is probably because they are loading the drivers as modules, or by chance the kernel is initializing the cards in the order they expect. There is no guarantee that will stay consistent. Question; will the following work reliably? IANAD (I Am Not A Developer) which is why I'm asking. * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS* * drivers are built as modules, not built-in into the kernel * is it possible to set things up so that the network driver modules do not load automatically at bootup? * have a script in /etc/local.d/ (or wherever) modprobe the drivers in the desired order I can see complications involving services that depend on net (e.g. sshd), but in general, would it work reliably? I.e. would the order of initial modprobe'ing determine the device names (eth/0/1/2/etc)? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-01, Michael Mol mike...@gmail.com wrote: On 04/01/2013 03:26 PM, William Hubbs wrote: You know that both udev and eudev have exactly the same issue with separate /usr right? The problem there isn't in the udev code, but it has to do with what is happening in rules that other packages install. As I recall, the problem is where the ebuild choses to install the code. Putting the udev code under /usr forces the issue on systems where it would otherwise not be an issue. Putting the udev code under / avoids that issue, but opens up the system to the silently fail thing upstream liked to use as the basis of separate /usr is broken So, there are three conceivable configurations (initramfs notwithstanding): 1. With systems which don't require /usr binaries before /usr would be mounted, separate /usr is not a problem. 2. With systems which require /usr binaries for some features before /usr would be mounted, those features will silently fail. 3. With systems which require /usr binaries to mount /usr, all hell breaks loose. Putting the udev code under /usr moves all udev systems from group 2 into group 3. In a sense, this fixes those systems because the admin is forced to address the silent failures he was previously unaware of. It also means pissing off a bunch of people who had features silently failing...but they probably didn't know or care about those features in the first place. It also moves all systems from group 1 into group 3...which is simply wro= ng. So long as eudev keeps its install path at / instead of /usr, admins in group 1 will probably be perfectly happy. I'd guess nothing prevents the udev ebuild from doing so, too. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-02, Alan McKinnon alan.mckin...@gmail.com wrote: On 02/04/2013 21:13, Paul Hartman wrote: On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey pe...@humphrey.ukfsn.org wrote: The most important para to me in the news item was: The feature can also be completely disabled using net.ifnames=0 on the kernel command line. I just added that to my grub.conf entries and I sail blissfully on with eth0. I updated remote virtual server (xen guest) and added this same option, crossed my fingers and rebooted, eth0 was still there and I was happy. I did this to get exactly the same result: $ ls -al /etc/udev/rules.d/ total 8 drwxr-xr-x 2 root root 4096 Apr 1 15:10 . drwxr-xr-x 4 root root 4096 Mar 30 20:34 .. lrwxrwxrwx 1 root root9 Apr 1 15:10 80-net-name-slot.rules - /dev/null Like you, I happen to *like* eth0 and wlan0 on a laptop workstation :-) Sort of the same here, except that I use lan0 instead of eth0, because once in a while I use broadcom's wireless drivers instead of the kernel drivers, and the former assign an ethX name. Sadly, I still get some problems after resuming from hibernation: *sometimes*, the ethernet NIC won't be renamed lan0 (and remains eth0), and I have to rmmod and modprobe. Also sadly, the fact that several people go oh noes you can't use wlan0 when I try to get comments on how to fix the issue does not help a lot... -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 04/04/2013 10:10, Nuno J. Silva (aka njsg) wrote: Sort of the same here, except that I use lan0 instead of eth0, because once in a while I use broadcom's wireless drivers instead of the kernel drivers, and the former assign an ethX name. Sadly, I still get some problems after resuming from hibernation: *sometimes*, the ethernet NIC won't be renamed lan0 (and remains eth0), and I have to rmmod and modprobe. Also sadly, the fact that several people go oh noes you can't use wlan0 when I try to get comments on how to fix the issue does not help a lot... I hear you :-) The amount of FUD and misinformation surrounding the entire udev ecosystem over the past 6 months defies all belief. I don't think I've ever seen quite this much hysteria and mob-think in anything computing-related until now. And that includes SCO, which is saying something... I gets so bad that people are starting to make shit up to be worried about, instead of just reading the simple document that is right in front of their eyes that already fully and completely answers the question at hand -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-04 5:13 AM, Alan McKinnon alan.mckin...@gmail.com wrote: I gets so bad that people are starting to make shit up to be worried about, instead of just reading the simple document that is right in front of their eyes that already fully and completely answers the question at hand But Alan, haven't you read the recent (past couple of DAYS) emails in this very thread from people who followed the current 'simple document' you refer to and it did not work as advertised? I don't think these people are making this stuff up - are you saying you do? Not to mention the fact that this final/current seemingly complete document was way, way too late for the many people who ended up with totally broken systems, and *that* is what caused all of the 'hysteria and mob-think' you so condescendingly speak of. It is these reports that is causing me all kinds of fear/trepidation at this seemingly simple/benign update (as you seem to believe it is). So, again, I would really, really like a very simple answer as to the *best* way to retain the old way that is least likely to cause problems down the road (ie, if/when udev is subsumed by systemd). Currently I count 3 different ways. Or, as an alternative, *how* to switch to eudev (their web page does *not* have simple/precise instructions on how to switch, only a description of what it is) - ie, do I just emerge -C udev emerge -C virtual/udev emerge eudev? Or is there more to it?
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-03, Mick michaelkintz...@gmail.com wrote: On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote: Therefore, all's well that's still working! And AFAIR, on at least 2 of those machines, the 70-persistent-net.rules was never something I did manually. Right, it used to be auto-generated by udev scripts. With udev-200 you are meant to remove it along with any other files from your /etc/udev/rules.d/ Huh? I'm supposed to remove all the other rules files as well? If we're not supposed to have user-defined rules, how do I do things like get various USB/firewire devices named/symlinked properly so that my backup drive gets mounted in the right spot, my oscilloscope SW can find the right USB serial port, and so on... -- Grant Edwards grant.b.edwardsYow! I'll show you MY at telex number if you show me gmail.comYOURS ...
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 04/04/2013 10:59 AM, Grant Edwards wrote: On 2013-04-03, Mick michaelkintz...@gmail.com wrote: On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote: Therefore, all's well that's still working! And AFAIR, on at least 2 of those machines, the 70-persistent-net.rules was never something I did manually. Right, it used to be auto-generated by udev scripts. With udev-200 you are meant to remove it along with any other files from your /etc/udev/rules.d/ Huh? I'm supposed to remove all the other rules files as well? If we're not supposed to have user-defined rules, how do I do things like get various USB/firewire devices named/symlinked properly so that my backup drive gets mounted in the right spot, my oscilloscope SW can find the right USB serial port, and so on... You're supposed to remove all the files in there that you did not yourself create. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Wed, 3 Apr 2013 16:38:28 + (UTC), Grant Edwards wrote: Have you read the news item? Yes. I found it rather confusing. It refers to a new format for rules, but the examples use the exact same format as the old rules. Poor choice of terminology there, the format is the same only the chosen namespace is different. It talks about how 80-net-name-slot.rules needs to be either an empty file or a synmlink to /dev/null if you want to disable the new naming scheme -- but that doesn't seem to be right. After the upgrade my 80-net-name-slot.rules file was neither an empty file nor a symlink to /dev/null, but I'm still getting the same old names. Do you have a 70-persistent-net.rules file? That would override to give the old names, which is why the news item tells you to change it If the system still has old network interface renaming rules in /etc/udev/rules.d, like 70-persistent-net.rules, those will need to be either modified or removed. It explains why the file should be renamed and also why you should change the names in the rules to not use ethN. The only explanation I found was the old way is now deprecated. My bad, I thought that was covered in the news item, but it is left to one of the linked pages to explain it. -- Neil Bothwick The voices in my head may not be real, but they have some good ideas! signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Thu, 04 Apr 2013 09:07:00 -0400, Tanstaafl wrote: Not to mention the fact that this final/current seemingly complete document was way, way too late for the many people who ended up with totally broken systems, and *that* is what caused all of the 'hysteria and mob-think' you so condescendingly speak of. This time the news was released before the update became available, although for something as potentially system-breaking as this, the gap should have been several days larger IMO. So, again, I would really, really like a very simple answer as to the *best* way to retain the old way that is least likely to cause problems down the road (ie, if/when udev is subsumed by systemd). Currently I count 3 different ways The no.ifrename kernel option mentioned in the news item. Or, as an alternative, *how* to switch to eudev (their web page does *not* have simple/precise instructions on how to switch, only a description of what it is) - ie, do I just emerge -C udev emerge -C virtual/udev emerge eudev? Or is there more to it? quickpkg udev emerge -Ca udev emerge -1a eudev Don't try removing virtual/udev, that is depended on by several packages (and probably system) but is satisfied by eudev. The only gotcha I found is that the USE flags for eudev must match those for eudev, so if you have anything udev-related in /etc/portage/package.use, make sure it applies to eudev too. -- Neil Bothwick Did you hear about the blind prostitute? You have to hand it to her. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Wed, Apr 03, 2013 at 11:28:10PM +0100, Mick wrote: On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote: Therefore, all's well that's still working! And AFAIR, on at least 2 of those machines, the 70-persistent-net.rules was never something I did manually. Right, it used to be auto-generated by udev scripts. With udev-200 you are meant to remove it along with any other files from your /etc/udev/rules.d/ If you left them there and their syntax is still valid, then udev will parse them and do as is told. -- Regards, Mick Why are we meant to remove it? Why would we remove them, since they're working? My kernel(s) all have eth* and none of that weirdness others reported. Thanks, Bruce -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Thu, Apr 04, 2013 at 05:05:06PM +0100, Neil Bothwick wrote On Thu, 04 Apr 2013 09:07:00 -0400, Tanstaafl wrote: Or, as an alternative, *how* to switch to eudev (their web page does *not* have simple/precise instructions on how to switch, only a description of what it is) - ie, do I just emerge -C udev emerge -C virtual/udev emerge eudev? Or is there more to it? quickpkg udev emerge -Ca udev emerge -1a eudev A bit more detail... *WARNING* do the following in sequence, quickly, and do *NOT* reboot until after step 7) 1) Optional fallback... quickpkg udev 2) Keyword sys-fs/eudev/eudev-1_beta2-r2 (~x86 or ~amd64 or whatever is correct for your machine) 3) Remove udev... emerge -Ca udev 4) Install eudev... emerge -1a eudev NOTE; eudev is a drop-in replacement for udev, and generates the same file names. With that in mind, the next 2 items make sense... 5) Stop the old udev demon and start the new one with the command... /etc/init.d/udev --nodeps restart 6) Do *NOT* remove virtual/udev and do *NOT* remove the udev service with rc-update 7) Follow any additional instructions you may get as ewarn messages or in /var/log/portage/elog -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-02, Neil Bothwick n...@digimed.co.uk wrote: On Tue, 2 Apr 2013 20:31:10 + (UTC), Grant Edwards wrote: In Flameyes blog, he showed an example of using udev rules pretty much identical to the ones I already had, so I couldn't figure out what was different (other than the default interface names, which still aren't really predictable). They are totally predictable, As long as you know the PCI bus IDs of the slots, which board is plugged into which slot, the PCI bus IDs of the USB controllers, and which USB ports are connected to which controllers, and so on. For most of us that equates to not predictable. :) The one thing (AFAICT) that does sort of make them what I would call predictable is the support for BIOS labels for ports. I've never actually seen a machine that supported that. since the names are specified in the rules, so you can predict what the interface will be called, In _theory_ you can, but you need to gather a lot of very low-level information first. In practice, I bet nobody does that -- they just boot up the kernel and see what they get. it's what the rules file says it will be called. However, the important issue is persistence, whatever name an interface has is the name it will always have. Until you move it to a different USB port or PCI slot. Names still aren't persistent (or, in practical terms, predictable), they're just based on a different parameter than they used to be. For some people the new 'prameter' is apparently more useful -- so I guess it's an improvement. The rules renaming within the kernel namespace, eth, wlan etc, could not guarantee that because of race conditions, and the so-called persistent names from the new udev still cannot do the same for devices that can be physically moved (mainly USB). The simplest solution is to do what the news item suggests, rename the persistent-net rules file Why does the file need to be renamed? and rename the interfaces within it to not clash with the kernel. So the kernel is still using the names eth[0-n]? And there's a race condition if I use the names eth[0-n] in my rules? Same as before? That's all you need to worry about when going from 197 to 200, upgrading from earlier versions means you should act on the parts about DEVTMPFS and runlevel files. -- Grant Edwards grant.b.edwardsYow! My life is a patio at of fun! gmail.com
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Wed, 3 Apr 2013 15:13:12 + (UTC), Grant Edwards wrote: On 2013-04-02, Neil Bothwick n...@digimed.co.uk wrote: On Tue, 2 Apr 2013 20:31:10 + (UTC), Grant Edwards wrote: In Flameyes blog, he showed an example of using udev rules pretty much identical to the ones I already had, so I couldn't figure out what was different (other than the default interface names, which still aren't really predictable). They are totally predictable, As long as you know the PCI bus IDs of the slots, which board is plugged into which slot, the PCI bus IDs of the USB controllers, and which USB ports are connected to which controllers, and so on. For most of us that equates to not predictable. :) We're at cross-purposes here. You mentioned udev rules, which I took to mean user-installed rules in /etc/udev. The names udev comes up with in the absence of any rules are not completely predictable, nor persistent. [snip more cross-purpose confusion] The simplest solution is to do what the news item suggests, rename the persistent-net rules file Why does the file need to be renamed? and rename the interfaces within it to not clash with the kernel. So the kernel is still using the names eth[0-n]? And there's a race condition if I use the names eth[0-n] in my rules? Same as before? Have you read the news item? It explains why the file should be renamed and also why you should change the names in the rules to not use ethN. -- Neil Bothwick My Go this amn keyboar oesn't have any 's. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 02-Apr-13 21:58, Alan McKinnon wrote: On 02/04/2013 21:41, Tanstaafl wrote: Are you saying that now, with udev-200, the default is the OLD way, and you have to intentionally enable the NEW way?? No, you are stilling misunderstanding. The news item goes to great lengths to explain that there is a new way and it is different from the old way. Jarry mentioned an EMPTY file, not an absent file. The ebuild does not install an empty file, so it is not the default. Well, believe me or not, but I had empty (only comments) file /etc/udev/rules.d/80-net-name-slot.rules : -- # Udev 197 and above has implemented predictable network interface names ... # To activate this function, move this file to a name that doesn't end # in .rules, or remove it then reboot your system -- And I am pretty sure I did not create it manually, so it must have come previously with some stable package, maybe udev197 (it has 25-Jan-2013 time-stamp). So yes, I had to activate new interface names manually by renaming the above mentioned file... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-03, Neil Bothwick n...@digimed.co.uk wrote: Have you read the news item? Yes. I found it rather confusing. It refers to a new format for rules, but the examples use the exact same format as the old rules. It talks about how 80-net-name-slot.rules needs to be either an empty file or a synmlink to /dev/null if you want to disable the new naming scheme -- but that doesn't seem to be right. After the upgrade my 80-net-name-slot.rules file was neither an empty file nor a symlink to /dev/null, but I'm still getting the same old names. It explains why the file should be renamed and also why you should change the names in the rules to not use ethN. The only explanation I found was the old way is now deprecated. -- Grant Edwards grant.b.edwardsYow! Kids, don't gross me at off ... Adventures with gmail.comMENTAL HYGIENE can be carried too FAR!
Re: [gentoo-user] Re: Udev update and persistent net rules changes
And if it's confusing for the 'bit jockeys' on this mailing list what do you think will be the effect on the casual user? This could have been handled better, imho. What happened to that documentation mojo Gentoo is known for? The post-install notes are a real head scratcher. On Apr 3, 2013 9:40 AM, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2013-04-03, Neil Bothwick n...@digimed.co.uk wrote: Have you read the news item? Yes. I found it rather confusing. It refers to a new format for rules, but the examples use the exact same format as the old rules. It talks about how 80-net-name-slot.rules needs to be either an empty file or a synmlink to /dev/null if you want to disable the new naming scheme -- but that doesn't seem to be right. After the upgrade my 80-net-name-slot.rules file was neither an empty file nor a symlink to /dev/null, but I'm still getting the same old names. It explains why the file should be renamed and also why you should change the names in the rules to not use ethN. The only explanation I found was the old way is now deprecated. -- Grant Edwards grant.b.edwardsYow! Kids, don't gross me at off ... Adventures with gmail.comMENTAL HYGIENE can be carried too FAR!
[gentoo-user] Re: Udev update and persistent net rules changes
Hi, Grant Edwards wrote: On 2013-04-03, Neil Bothwick n...@digimed.co.uk wrote: Have you read the news item? Yes. I found it rather confusing. It refers to a new format for rules, but the examples use the exact same format as the old rules. It talks about how 80-net-name-slot.rules needs to be either an empty file or a synmlink to /dev/null if you want to disable the new naming scheme -- but that doesn't seem to be right. After the upgrade my 80-net-name-slot.rules file was neither an empty file nor a symlink to /dev/null, but I'm still getting the same old names. same for me. I followed the upgrade guide and removed any 70-* files, renamed the net.eth0 link to the new scheme net.enp0s1 just to to find out that the kernel could not bring up a network with the such a device. The machine booted fine after using eth0 instead again. One a second machine I kept eth0 immediately and it booted without problems afterwards. It explains why the file should be renamed and also why you should change the names in the rules to not use ethN. The only explanation I found was the old way is now deprecated. And the new name simply did not work. - Jörg
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Wed, Apr 03, 2013 at 08:06:20PM +0200, Jörg Schaible wrote:
Hi,
Grant Edwards wrote:
On 2013-04-03, Neil Bothwick n...@digimed.co.uk wrote:
Have you read the news item?
Yes. I found it rather confusing.
It refers to a new format for rules, but the examples use the exact
same format as the old rules.
It talks about how 80-net-name-slot.rules needs to be either an empty
file or a synmlink to /dev/null if you want to disable the new naming
scheme -- but that doesn't seem to be right. After the upgrade my
80-net-name-slot.rules file was neither an empty file nor a symlink to
/dev/null, but I'm still getting the same old names.
same for me. I followed the upgrade guide and removed any 70-* files,
renamed the net.eth0 link to the new scheme net.enp0s1 just to to find out
that the kernel could not bring up a network with the such a device. The
machine booted fine after using eth0 instead again. One a second machine I
kept eth0 immediately and it booted without problems afterwards.
It explains why the file should be renamed and also why you should
change the names in the rules to not use ethN.
The only explanation I found was the old way is now deprecated.
And the new name simply did not work.
- Jörg
When the news item is too convoluted to understand without writing it on
paper, and doing a diagram of my LAN, I just get out the USB SystemRescueCD
and have it ready on first reboot. So far I've just sailed along as it's been
since before last March or so when WilliamH first put out the news item about
udev about to fubar the universe. I'd not wanted to go to or past udev-181,
but kerframil told me to stop being scared and upgrade to stable, so I did.
And here are the results, just upgrading, not changing ANY file:
mingdao@router ~ $ less /etc/udev/rules.d/80-net-name-slot.rules
/etc/udev/rules.d/80-net-name-slot.rules: No such file or directory
mingdao@router ~ $ eix sys-fs/udev
[I] sys-fs/udev
Available versions: [M]171-r10 197-r8^t ~198-r6^t ~199-r1^t 200^t
**^t {{acl action_modeswitch build debug doc edd extras +firmware-loader
floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux
static-libs test}}
Installed versions: 200^t(05:01:58 PM 04/02/2013)(acl firmware-loader
kmod openrc -doc -gudev -hwdb -introspection -keymap -selinux -static-libs)
Homepage:http://www.freedesktop.org/wiki/Software/systemd
Description: Linux dynamic and persistent device naming support
(aka userspace devfs)
[I] sys-fs/udev-init-scripts
Available versions: 23^t ~24^t 25^t **^t
Installed versions: 25^t(05:02:08 PM 04/02/2013)
Homepage:http://www.gentoo.org
Description: udev startup scripts for openrc
Found 2 matches.
mingdao@router ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==68:05:ca:03:05:5d, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth0
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==68:05:ca:03:05:50, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth1
# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==f4:6d:04:e8:1d:d9, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth2
mingdao@server ~ $ less /etc/udev/rules.d/80-net-name-slot.rules
/etc/udev/rules.d/80-net-name-slot.rules: No such file or directory
mingdao@server ~ $ eix sys-fs/udev
[I] sys-fs/udev
Available versions: [M]171-r10 197-r8^t ~198-r6^t ~199-r1^t 200^t
**^t {{acl action_modeswitch build debug doc edd extras +firmware-loader
floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux
static-libs test}}
Installed versions: 200^t(06:01:45 PM 04/02/2013)(acl firmware-loader
kmod openrc -doc -gudev -hwdb -introspection -keymap -selinux -static-libs)
Homepage:http://www.freedesktop.org/wiki/Software/systemd
Description: Linux dynamic and persistent device naming support
(aka userspace devfs)
[I] sys-fs/udev-init-scripts
Available versions: 23^t ~24^t 25^t **^t
Installed versions: 25^t(06:01:58 PM 04/02/2013)
Homepage:http://www.gentoo.org
Description: udev startup scripts for openrc
Found 2 matches.
mingdao@server ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote: Therefore, all's well that's still working! And AFAIR, on at least 2 of those machines, the 70-persistent-net.rules was never something I did manually. Right, it used to be auto-generated by udev scripts. With udev-200 you are meant to remove it along with any other files from your /etc/udev/rules.d/ If you left them there and their syntax is still valid, then udev will parse them and do as is told. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey pe...@humphrey.ukfsn.org wrote: The most important para to me in the news item was: The feature can also be completely disabled using net.ifnames=0 on the kernel command line. I just added that to my grub.conf entries and I sail blissfully on with eth0. I updated remote virtual server (xen guest) and added this same option, crossed my fingers and rebooted, eth0 was still there and I was happy.
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 02/04/2013 21:13, Paul Hartman wrote: On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey pe...@humphrey.ukfsn.org wrote: The most important para to me in the news item was: The feature can also be completely disabled using net.ifnames=0 on the kernel command line. I just added that to my grub.conf entries and I sail blissfully on with eth0. I updated remote virtual server (xen guest) and added this same option, crossed my fingers and rebooted, eth0 was still there and I was happy. I did this to get exactly the same result: $ ls -al /etc/udev/rules.d/ total 8 drwxr-xr-x 2 root root 4096 Apr 1 15:10 . drwxr-xr-x 4 root root 4096 Mar 30 20:34 .. lrwxrwxrwx 1 root root9 Apr 1 15:10 80-net-name-slot.rules - /dev/null Like you, I happen to *like* eth0 and wlan0 on a laptop workstation :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 02-Apr-13 21:13, Paul Hartman wrote: On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey pe...@humphrey.ukfsn.org wrote: The most important para to me in the news item was: The feature can also be completely disabled using net.ifnames=0 on the kernel command line. I just added that to my grub.conf entries and I sail blissfully on with eth0. I updated remote virtual server (xen guest) and added this same option, crossed my fingers and rebooted, eth0 was still there and I was happy. I think it is not necessary to add any options. If after upgrading to udev200 you do not do anything, after reboot you still have eth0. Empty 80-net-name-slot.rules takes care of it... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-02 3:21 PM, Jarry mr.ja...@gmail.com wrote: On 02-Apr-13 21:13, Paul Hartman wrote: On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey pe...@humphrey.ukfsn.org wrote: The most important para to me in the news item was: The feature can also be completely disabled using net.ifnames=0 on the kernel command line. I just added that to my grub.conf entries and I sail blissfully on with eth0. I updated remote virtual server (xen guest) and added this same option, crossed my fingers and rebooted, eth0 was still there and I was happy. I think it is not necessary to add any options. If after upgrading to udev200 you do not do anything, after reboot you still have eth0. Empty 80-net-name-slot.rules takes care of it... ? Are you saying that now, with udev-200, the default is the OLD way, and you have to intentionally enable the NEW way?? This is mind-boggling.
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 02/04/2013 21:41, Tanstaafl wrote: On 2013-04-02 3:21 PM, Jarry mr.ja...@gmail.com wrote: On 02-Apr-13 21:13, Paul Hartman wrote: On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey pe...@humphrey.ukfsn.org wrote: The most important para to me in the news item was: The feature can also be completely disabled using net.ifnames=0 on the kernel command line. I just added that to my grub.conf entries and I sail blissfully on with eth0. I updated remote virtual server (xen guest) and added this same option, crossed my fingers and rebooted, eth0 was still there and I was happy. I think it is not necessary to add any options. If after upgrading to udev200 you do not do anything, after reboot you still have eth0. Empty 80-net-name-slot.rules takes care of it... ? Are you saying that now, with udev-200, the default is the OLD way, and you have to intentionally enable the NEW way?? This is mind-boggling. No, you are stilling misunderstanding. The news item goes to great lengths to explain that there is a new way and it is different from the old way. Jarry mentioned an EMPTY file, not an absent file. The ebuild does not install an empty file, so it is not the default. All the questions you have raised are clearly explained in the news item. Please read it and study it, it really is complete. You appear to be confusing yourself by adding things that are not there. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-04-02, Alan McKinnon alan.mckin...@gmail.com wrote: No, you are stilling misunderstanding. He's not the only one. The news item goes to great lengths to explain that there is a new way and it is different from the old way. I did grok that much. I had a 70-persistent-net.rules file that named my three interfaces eth0 eth1 and eth2 based on their MAC addresses. After reading the news item and flameeyes blog, I was still pretty much at a loss regarding what I was actually supposed to _do_. In Flameyes blog, he showed an example of using udev rules pretty much identical to the ones I already had, so I couldn't figure out what was different (other than the default interface names, which still aren't really predictable). In the end, I just did the upgrade and rebooted. My existing rules seemed to work fine: the interfaces came up with the same names as before. So I gave up trying to figure it out... -- Grant Edwards grant.b.edwardsYow! Of course, you at UNDERSTAND about the PLAIDS gmail.comin the SPIN CYCLE --
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 02/04/2013 22:31, Grant Edwards wrote: On 2013-04-02, Alan McKinnon alan.mckin...@gmail.com wrote: No, you are stilling misunderstanding. He's not the only one. The news item goes to great lengths to explain that there is a new way and it is different from the old way. I did grok that much. I had a 70-persistent-net.rules file that named my three interfaces eth0 eth1 and eth2 based on their MAC addresses. After reading the news item and flameeyes blog, I was still pretty much at a loss regarding what I was actually supposed to _do_. In Flameyes blog, he showed an example of using udev rules pretty much identical to the ones I already had, so I couldn't figure out what was different (other than the default interface names, which still aren't really predictable). In the end, I just did the upgrade and rebooted. My existing rules seemed to work fine: the interfaces came up with the same names as before. So I gave up trying to figure it out... That is the expected result - you have explicit udev rules that lay out how you want every interface to be named, and udev did what you told it to do. The issue at hand, for the most part, is what udev will do if you *don't* have explicit unambiguous rules, i.e. you leave it up to the software to make a decision. The new version is most likely going to do something different to what earlier versions did. That's not hard to understand. The trick with all this new udev stuff is to read what is coming out of the horse's mouth and ignore all the frenetic noise that the internet is spewing out. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Am Tue, 2 Apr 2013 20:31:10 + (UTC) schrieb Grant Edwards grant.b.edwa...@gmail.com: On 2013-04-02, Alan McKinnon alan.mckin...@gmail.com wrote: No, you are stilling misunderstanding. He's not the only one. The news item goes to great lengths to explain that there is a new way and it is different from the old way. I did grok that much. I had a 70-persistent-net.rules file that named my three interfaces eth0 eth1 and eth2 based on their MAC addresses. After reading the news item and flameeyes blog, I was still pretty much at a loss regarding what I was actually supposed to _do_. AFAIU, as soon as the names in your rules file differ from the in-kernel names (e.g., if the kernel switches eth0 and eth1), bad things can happen during renaming, due to deadlocks or something like that (others will have understood it better and should explain it rather than I). So, again AFAIU, it's enough to change the network device names from eth* to net*, or whatever you desire (I went with Flameeyes naming scheme). The important thing is that your device names *don't* use the in-kernel namespace eth*. See section 3 Old interface naming rules in the news item and the references therein. The new default naming scheme is AFAICT orthogonal to that. HTH -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Am Tue, 2 Apr 2013 23:15:40 +0200 schrieb Marc Joliet mar...@gmx.de: Am Tue, 2 Apr 2013 20:31:10 + (UTC) schrieb Grant Edwards grant.b.edwa...@gmail.com: On 2013-04-02, Alan McKinnon alan.mckin...@gmail.com wrote: No, you are stilling misunderstanding. He's not the only one. The news item goes to great lengths to explain that there is a new way and it is different from the old way. I did grok that much. I had a 70-persistent-net.rules file that named my three interfaces eth0 eth1 and eth2 based on their MAC addresses. After reading the news item and flameeyes blog, I was still pretty much at a loss regarding what I was actually supposed to _do_. AFAIU, as soon as the names in your rules file differ from the in-kernel names (e.g., if the kernel switches eth0 and eth1), bad things can happen during renaming, due to deadlocks or something like that (others will have understood it better and should explain it rather than I). OK, I should have looked first. Here's a technical explanation from http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames (referenced in the news item, BTW): For a longer time udev shipped support for assigning permanent ethX names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: [snipped various other reasons]. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same ethX namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back. So not a deadlock, but a race condition. -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Tue, 2 Apr 2013 20:31:10 + (UTC), Grant Edwards wrote: In Flameyes blog, he showed an example of using udev rules pretty much identical to the ones I already had, so I couldn't figure out what was different (other than the default interface names, which still aren't really predictable). They are totally predictable, since the names are specified in the rules, so you can predict what the interface will be called, it's what the rules file says it will be called. However, the important issue is persistence, whatever name an interface has is the name it will always have. The rules renaming within the kernel namespace, eth, wlan etc, could not guarantee that because of race conditions, and the so-called persistent names from the new udev still cannot do the same for devices that can be physically moved (mainly USB). The simplest solution is to do what the news item suggests, rename the persistent-net rules file and rename the interfaces within it to not clash with the kernel. That's all you need to worry about when going from 197 to 200, upgrading from earlier versions means you should act on the parts about DEVTMPFS and runlevel files. -- Neil Bothwick Am I ignorant or apathetic? I don't know and don't care! signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Apr 1, 2013 2:10 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 31/03/2013 20:26, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, It's more accurate to say it worked by accident rather than by design. (Sort of like how the power utility gets power to your house - if yours is anything like mine I get power despite their best efforts to not give me any ...) Anyway, the old method sucked and it sort of works for you and I because we don't add anything ourselves that trip it up. But this new method... geez lads, I just dunno. How do Windows, Mac and Android deal with this stuff? They don't seem to have any device naming problems, so what is the magic solution in use on those platforms? I'm not sure about Macs and Android, but with Windows it all happens based on MAC address. I found about it quite accidentally; I had exported a VM from XenServer and imported it to a different host. By default, XenServer assigns a new, random MAC for imported VMs. Windows saw this and proceeded to initialize a new NIC. When I tried setting the IP settings, it complained that the settings are currently being used by an invisible NIC. So, I shut down the VM, restored the old MAC, and the prior settings reappeared. Rgds, --
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 21:34:51 +0100, Kevin Chadwick wrote: What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. Fair point but wouldn't that be only if you plug in two of the same type that the names may switch? According to Flameyes' blog, if you have only one adaptor, its name will change according to the port used, which is a rather different definition of persistent than I have been used to. -- Neil Bothwick All mail what i send is thoughly proof-red, definately! signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Mon, 01 Apr 2013 03:02:51 +0200, Volker Armin Hemmann wrote: What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. congratulation, you just found another reason why today's udev sucks. I take no credit for it, Flameyes pointed that one out. -- Neil Bothwick Not one shred of evidence supports the notion that life is serious. signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: I find the OpenBSD method of different names like fxp0 usefuk You can emulate that with suitable (e)udev rules. -- Neil Bothwick Computers are like Old Testament gods; lots of rules and no mercy. signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Apr 1, 2013 1:54 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 31 Mar 2013 21:34:51 +0100, Kevin Chadwick wrote: What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. Fair point but wouldn't that be only if you plug in two of the same type that the names may switch? According to Flameyes' blog, if you have only one adaptor, its name will change according to the port used, which is a rather different definition of persistent than I have been used to. -- Neil Bothwick All mail what i send is thoughly proof-red, definately! True, that. I still don't understand what's so bad with MAC-based identification? I mean, uniqueness defined through MAC Address identity, the system name is just a label... Rgds, --
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Mon, 1 Apr 2013 13:57:42 +0700, Pandu Poluan wrote: I still don't understand what's so bad with MAC-based identification? I mean, uniqueness defined through MAC Address identity, the system name is just a label... MAC addresses are not human-friendly. It would be OK if you could set up aliases, so your firewall rules could use enaabbccddeeff while you could still type eth0. -- Neil Bothwick Don't just read the Tagline; read the MESSAGE! signature.asc Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 16:19:18 -0400, Tanstaafl wrote: What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting:) So, just ln -s net.net0 - net.lo Then after reboot, you can rm net.eth0 - net.lo ? You also need to rc-update add net.net0 default -- Neil Bothwick WinErr 003: Dynamic linking error - Your mistake is now in every file signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On 04/01/2013 09:12 AM, Neil Bothwick wrote: On Mon, 1 Apr 2013 13:57:42 +0700, Pandu Poluan wrote: I still don't understand what's so bad with MAC-based identification? I mean, uniqueness defined through MAC Address identity, the system name is just a label... MAC addresses are not human-friendly. It would be OK if you could set up aliases, so your firewall rules could use enaabbccddeeff while you could still type eth0. Frankly, I never found 'eth0' to be particularly friendly, either. Hence why I like naming my interfaces things like 'wan', 'wifilan' and 'wiredlan'. signature.asc Description: OpenPGP digital signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Mon, 1 Apr 2013 14:12:17 +0100 Neil Bothwick n...@digimed.co.uk wrote: I still don't understand what's so bad with MAC-based identification? I mean, uniqueness defined through MAC Address identity, the system name is just a label... MAC addresses are not human-friendly. It would be OK if you could set up aliases, so your firewall rules could use enaabbccddeeff while you could still type eth0. It used to be dead easy to link the MAC to the device type and number from dmesg without looking up the MAC to Manufacturer codes. A lot of useful information seems to have been removed from the linux dmesg? atleast on 3.2 kernels.
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Mon, 01 Apr 2013 09:29:08 -0400, Michael Mol wrote: MAC addresses are not human-friendly. It would be OK if you could set up aliases, so your firewall rules could use enaabbccddeeff while you could still type eth0. Frankly, I never found 'eth0' to be particularly friendly, either. Hence why I like naming my interfaces things like 'wan', 'wifilan' and 'wiredlan'. Relative to 'lan' or 'wan', no, but relative to an embedded MAC address? -- Neil Bothwick I don't know if I can assimilate one more Borg Tagline! signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On 04/01/2013 09:54 AM, Neil Bothwick wrote: On Mon, 01 Apr 2013 09:29:08 -0400, Michael Mol wrote: MAC addresses are not human-friendly. It would be OK if you could set up aliases, so your firewall rules could use enaabbccddeeff while you could still type eth0. Frankly, I never found 'eth0' to be particularly friendly, either. Hence why I like naming my interfaces things like 'wan', 'wifilan' and 'wiredlan'. Relative to 'lan' or 'wan', no, but relative to an embedded MAC address? Honestly, with IPv6, I get so accustomed to recognizing the last three or four octets of MAC addresses, that idea is starting to grow on me, too! It's like recognizing phone numbers, really. You eventually just start remembering enough of the thing to be useful. If the system isn't smart enough to apply a solid semantic name (like my 'wan', 'wifilan' or 'wiredlan'), I'd rather it not try to apply a semantic name (eth0 or net0) at all. But you're hearing this come from a C++ programmer turned network admin, so take that with a grain of salt. :) signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 18:37:07 + (UTC) Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. And, at least now, I have got enough knowledge to know whether it affects me or not. But the sad thing is that I got most of that knowledge *after* the first of these versions without the old script was stabilized. Another sad thing is that if you want to find out about the option to keep the old-style naming rules, Udev/upgrade page https://wiki.gentoo.org/wiki/Udev/upgrade just links to bug 453494, so instead of a guide, users get to read a bug entry with 94 comments (and counting). I went with the new persistent names because it seemed simpler and because there was relatively clearer information about how it should be done. Once upon a time, for an upgrade like this, Gentoo would have produced a guide summarizing the pros and cons of the two courses of actions along with a recipe for each one. (Or if not a recipe, at least a list of all the considerations needed for each path.)
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. And, at least now, I have got enough knowledge to know whether it affects me or not. But the sad thing is that I got most of that knowledge *after* the first of these versions without the old script was stabilized. I switched to eudev when the separate /usr thing popped up. While I am watching this thread and sort of taking mental notes, I'm hoping this is not a eudev thing, even in the future. You know that both udev and eudev have exactly the same issue with separate /usr right? The problem there isn't in the udev code, but it has to do with what is happening in rules that other packages install. William pgpMndIm0sIM4.pgp Description: PGP signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 04/01/2013 03:26 PM, William Hubbs wrote: On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. And, at least now, I have got enough knowledge to know whether it affects me or not. But the sad thing is that I got most of that knowledge *after* the first of these versions without the old script was stabilized. I switched to eudev when the separate /usr thing popped up. While I am watching this thread and sort of taking mental notes, I'm hoping this is not a eudev thing, even in the future. You know that both udev and eudev have exactly the same issue with separate /usr right? The problem there isn't in the udev code, but it has to do with what is happening in rules that other packages install. As I recall, the problem is where the ebuild choses to install the code. Putting the udev code under /usr forces the issue on systems where it would otherwise not be an issue. Putting the udev code under / avoids that issue, but opens up the system to the silently fail thing upstream liked to use as the basis of separate /usr is broken So, there are three conceivable configurations (initramfs notwithstanding): 1. With systems which don't require /usr binaries before /usr would be mounted, separate /usr is not a problem. 2. With systems which require /usr binaries for some features before /usr would be mounted, those features will silently fail. 3. With systems which require /usr binaries to mount /usr, all hell breaks loose. Putting the udev code under /usr moves all udev systems from group 2 into group 3. In a sense, this fixes those systems because the admin is forced to address the silent failures he was previously unaware of. It also means pissing off a bunch of people who had features silently failing...but they probably didn't know or care about those features in the first place. It also moves all systems from group 1 into group 3...which is simply wrong. So long as eudev keeps its install path at / instead of /usr, admins in group 1 will probably be perfectly happy. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Michael Mol wrote: On 04/01/2013 03:26 PM, William Hubbs wrote: On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. And, at least now, I have got enough knowledge to know whether it affects me or not. But the sad thing is that I got most of that knowledge *after* the first of these versions without the old script was stabilized. I switched to eudev when the separate /usr thing popped up. While I am watching this thread and sort of taking mental notes, I'm hoping this is not a eudev thing, even in the future. You know that both udev and eudev have exactly the same issue with separate /usr right? The problem there isn't in the udev code, but it has to do with what is happening in rules that other packages install. As I recall, the problem is where the ebuild choses to install the code. Putting the udev code under /usr forces the issue on systems where it would otherwise not be an issue. Putting the udev code under / avoids that issue, but opens up the system to the silently fail thing upstream liked to use as the basis of separate /usr is broken So, there are three conceivable configurations (initramfs notwithstanding): 1. With systems which don't require /usr binaries before /usr would be mounted, separate /usr is not a problem. 2. With systems which require /usr binaries for some features before /usr would be mounted, those features will silently fail. 3. With systems which require /usr binaries to mount /usr, all hell breaks loose. Putting the udev code under /usr moves all udev systems from group 2 into group 3. In a sense, this fixes those systems because the admin is forced to address the silent failures he was previously unaware of. It also means pissing off a bunch of people who had features silently failing...but they probably didn't know or care about those features in the first place. It also moves all systems from group 1 into group 3...which is simply wrong. So long as eudev keeps its install path at / instead of /usr, admins in group 1 will probably be perfectly happy. +1 Happy I am. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Monday 01 April 2013 20:51:45 Michael Mol wrote: ---8 So, there are three conceivable configurations (initramfs notwithstanding): What a fine word! It's a while since I saw it last. 1. With systems which don't require /usr binaries before /usr would be mounted, separate /usr is not a problem. I'm in that group, I'm glad to be able to say. The most important para to me in the news item was: The feature can also be completely disabled using net.ifnames=0 on the kernel command line. I just added that to my grub.conf entries and I sail blissfully on with eth0. Of course this is a simple desktop box with a static network topology; on a less simple setup things would differ. Maybe I've left a hostage to fortune, but it'll do for now. ---8 -- Peter
[gentoo-user] Re: Udev update and persistent net rules changes
On 30/03/13 17:15, Tanstaafl wrote: Ok, just read the new news item and the linked udev-guide wiki page You should probably also read: http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names and: http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Nikos Chantziaras rea...@gmail.com wrote: On 30/03/13 17:15, Tanstaafl wrote: Ok, just read the new news item and the linked udev-guide wiki page You should probably also read: http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names and: http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names The feeling that I got while reading the first was exactly what the second talks about. We - from what I understand - had scripts automatically generating the name rules from MAC addresses, it's just that they generated stuff like ethX. Can't we just keep these scripts around (even if this was something provided by upstream and we would have to forge a new incarnation)? I mean, IMHO, net0, wl0, ... are much easier to deal with and understand than something physically-based. They also avoid problems caused by moving these cards around, or changes in the kernel drivers or BIOS, or BIOS settings that eventually end up exposing cards in a different way. The problem with the old approach was *just* the name clash that rendered the hacky approach unreliable. Maybe we could just fix the issue by using non-clashing namespaces, instead of pushing a completely different (and possibly less reliable) naming scheme by default. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: On 2013-03-31, Nikos Chantziaras rea...@gmail.com wrote: On 30/03/13 17:15, Tanstaafl wrote: Ok, just read the new news item and the linked udev-guide wiki page You should probably also read: http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names and: http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names The feeling that I got while reading the first was exactly what the second talks about. We - from what I understand - had scripts automatically generating the name rules from MAC addresses, it's just that they generated stuff like ethX. Can't we just keep these scripts around (even if this was something provided by upstream and we would have to forge a new incarnation)? I mean, IMHO, net0, wl0, ... are much easier to deal with and understand than something physically-based. They also avoid problems caused by moving these cards around, or changes in the kernel drivers or BIOS, or BIOS settings that eventually end up exposing cards in a different way. The problem with the old approach was *just* the name clash that rendered the hacky approach unreliable. Maybe we could just fix the issue by using non-clashing namespaces, instead of pushing a completely different (and possibly less reliable) naming scheme by default. Ok, after some chat on IRC, it seems that upstream made it rather non-trivial to have something like the old rule-generator, and that's why we can't simply move that from, e.g., ethX to, say, netX. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Mar 31, 2013 7:13 PM, Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: On 2013-03-31, Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: On 2013-03-31, Nikos Chantziaras rea...@gmail.com wrote: On 30/03/13 17:15, Tanstaafl wrote: Ok, just read the new news item and the linked udev-guide wiki page You should probably also read: http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names and: http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names The feeling that I got while reading the first was exactly what the second talks about. We - from what I understand - had scripts automatically generating the name rules from MAC addresses, it's just that they generated stuff like ethX. Can't we just keep these scripts around (even if this was something provided by upstream and we would have to forge a new incarnation)? I mean, IMHO, net0, wl0, ... are much easier to deal with and understand than something physically-based. They also avoid problems caused by moving these cards around, or changes in the kernel drivers or BIOS, or BIOS settings that eventually end up exposing cards in a different way. The problem with the old approach was *just* the name clash that rendered the hacky approach unreliable. Maybe we could just fix the issue by using non-clashing namespaces, instead of pushing a completely different (and possibly less reliable) naming scheme by default. Ok, after some chat on IRC, it seems that upstream made it rather non-trivial to have something like the old rule-generator, and that's why we can't simply move that from, e.g., ethX to, say, netX. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/ Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... Rgds, --
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... Rgds, -- I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. And, at least now, I have got enough knowledge to know whether it affects me or not. But the sad thing is that I got most of that knowledge *after* the first of these versions without the old script was stabilized. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. And, at least now, I have got enough knowledge to know whether it affects me or not. But the sad thing is that I got most of that knowledge *after* the first of these versions without the old script was stabilized. I switched to eudev when the separate /usr thing popped up. While I am watching this thread and sort of taking mental notes, I'm hoping this is not a eudev thing, even in the future. I'm just hoping people will be able to find a solution to this that works well for them. I especially wish that for those managing a remote system with little or no physical access. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 31/03/2013 20:26, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, It's more accurate to say it worked by accident rather than by design. (Sort of like how the power utility gets power to your house - if yours is anything like mine I get power despite their best efforts to not give me any ...) Anyway, the old method sucked and it sort of works for you and I because we don't add anything ourselves that trip it up. But this new method... geez lads, I just dunno. How do Windows, Mac and Android deal with this stuff? They don't seem to have any device naming problems, so what is the magic solution in use on those platforms? eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. Dale :-) :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 13:44:18 -0500, Dale wrote: I'm just hoping people will be able to find a solution to this that works well for them. I especially wish that for those managing a remote system with little or no physical access. Well I just updated a headless box, followed the instructions in the news article and it just worked. I now have net0 instead of eth0. What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting :) -- Neil Bothwick When told the reason for Daylight Saving time the old Indian said... Only a white man would believe that you could cut a foot off the top of a blanket And sew it to the bottom of a blanket and have a longer blanket. signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 11:48:19 + (UTC) Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: instead of pushing a completely different (and possibly less reliable) naming scheme by default. Whilst I wouldn't want them changing on me (though if your physically changing the pci slot then you should be able to handle the number change). I find the OpenBSD method of different names like fxp0 useful because it means you can look up the manpage for that card type which as long as the documentation is good is very useful.
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Alan McKinnon wrote: On 31/03/2013 20:26, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, It's more accurate to say it worked by accident rather than by design. (Sort of like how the power utility gets power to your house - if yours is anything like mine I get power despite their best efforts to not give me any ...) Anyway, the old method sucked and it sort of works for you and I because we don't add anything ourselves that trip it up. But this new method... geez lads, I just dunno. How do Windows, Mac and Android deal with this stuff? They don't seem to have any device naming problems, so what is the magic solution in use on those platforms? Well, it still works regardless of by accident or by design. On the rare occasion that I have to reboot/shutdown, when my system comes up, I still have the same network connection(s) I had before. I still have net.eth0 like I have had since I built this rig. On my old rig, same thing and I added networks cards to it, more than once I might add. Everything was consistent until I disabled the on board nic since it went bad then it got interesting because I had to configure things to let the first network card be the internet connection instead of the on board old one. I'm pretty sure that regardless of what was managing devices that I would still have had to tell it which interface to use tho. I mean, it can't exactly read my mind. lol Point is, just like the /usr mess, it's working just fine. Odd thing is, udev folks said it couldn't be fixed but the eudev folks seemed to have fixed it just fine. It seems Walter found his own fix too. Sort of like a plumber telling me I have to put with the drip when another plumber can replace the o-ring and stop the drip. So much for the first plumber. I'll loose his number for sure. Only with this, two plumbers had a better plan. One replaced the o-ring, one replaced the whole faucet. Still got rid of the drip tho. I generally look more at the results than the how. I'm not a programmer, just a user. End result is what I look for. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: instead of pushing a completely different (and possibly less reliable) naming scheme by default. Whilst I wouldn't want them changing on me (though if your physically changing the pci slot then you should be able to handle the number change). What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. -- Neil Bothwick B?#$^f, said Pooh, as line noise garbled his transmission. signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On 03/31/2013 03:55 PM, Neil Bothwick wrote: On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: instead of pushing a completely different (and possibly less reliable) naming scheme by default. Whilst I wouldn't want them changing on me (though if your physically changing the pci slot then you should be able to handle the number change). What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. Social media is infectious. I was looking for a '+1' button for this... signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31 3:37 PM, Neil Bothwick n...@digimed.co.uk wrote: What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting:) So, just ln -s net.net0 - net.lo Then after reboot, you can rm net.eth0 - net.lo ?
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 20:55:00 +0100 Neil Bothwick n...@digimed.co.uk wrote: What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. Fair point but wouldn't that be only if you plug in two of the same type that the names may switch? In which case there are various ways of solving the problem and name assignment may be handy in some cases, though I still think it would be good to have a man page linked to that name.
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 31 Mar 2013 13:44:18 -0500, Dale wrote: I'm just hoping people will be able to find a solution to this that works well for them. I especially wish that for those managing a remote system with little or no physical access.=20 Well I just updated a headless box, followed the instructions in the news article and it just worked. I now have net0 instead of eth0. What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting :) This one was mentioned and discussed in gentoo-dev. It's sad if this information didn't make it to the news item, but perhaps it was mentioned a bit too late. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sunday 31 Mar 2013 21:19:18 Tanstaafl wrote: On 2013-03-31 3:37 PM, Neil Bothwick n...@digimed.co.uk wrote: What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting:) So, just ln -s net.net0 - net.lo Then after reboot, you can rm net.eth0 - net.lo ? Worth noting that I did not remove /etc/init.d/net.eth0 and upon rebooting a box I couldn't connect to it via ssh! This was despite having changed the firewall interface in the iptables rules to the new NIC name. Thankfully I had physical access. sshd complained that net.eth0 was not available. I deleted the /etc/init.d/net.eth0 symlink and rebooted. No more problems. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 01/04/13 01:01, Dale wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... Rgds, -- I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. Dale :-) :-) Have not seen it yet (eudev), but something interesting is I am moving to a small cloud of libvirt managed vm instances for my services and instead of having to delete the net rules file in each instance (because the mac address is changing) it creates a new eth0 for the new mac address, and moved the old to eth1 - handy as I am using a base image and spawning off a child from a snap for each instance - one less annoyance to worry about! Seemed to happen about the time of the last eudev update, need to look into it more. BillK
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
Am 31.03.2013 21:55, schrieb Neil Bothwick: On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: instead of pushing a completely different (and possibly less reliable) naming scheme by default. Whilst I wouldn't want them changing on me (though if your physically changing the pci slot then you should be able to handle the number change). What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. congratulation, you just found another reason why today's udev sucks.
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-30, Tanstaafl tansta...@libertytrek.org wrote:
Ok, just read the new news item and the linked udev-guide wiki page, and
the only thing left that I'm unsure/concerned about now is the
persistent net rules changes...
The very last line on the wiki page says:
4. Known problems
Stale 70-persistent-net.rules (or other network rules) in
/etc/udev/rules.d can prevent the predictable network naming from being
enabled. Both 70-persistent-net.rules and 70-persistent-cd.rules are
from the now deleted rule_generator
These 'stale' 70- rules are all I have right now (again I'm still on
udev-171-r10), and while the wiki page doesn't say what to do with/about
them, it seems to hint that I could leave these in place and... they
would still work as they did previously (prevent the predictable network
naming from being enabled)?
My system (8+ years old) has a Tyan motherboard (S2895) with dual Gb
ethernet ports, with only one port currently used (but both are enabled
in the BIOS so both are listed in my current rules file).
(And, more importantly, they're seen and handled by the running kernel.)
[...]
Contents of 70-persistent-net.rules:
# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:e0:81:54:9c:8b,
KERNEL==eth*, NAME=eth1
# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:e0:81:54:9c:8a,
KERNEL==eth*, NAME=eth0
So... after reading the new news item, am I right that all I need to do
to make sure that my network comes up properly is... edit the 80-*
rule(s) that are created after udev is updated to make sure the same
adapters that were named eth0/1 are now named net0/1, and the kernel
will now take care of naming net0/1 eth0/1?
You can either remove it and get what udev gives you (a bit more
cryptic, but it is supposed to be somewhat persistent unless the cards
are moved around, or there are major kernel changes), or you can give
them the names you want, as far as it's not ethX.
But you will always have to update other config files (firewall, init
scripts, etc.) to have the new names.
Also, is it critical to remove (or at least rename) the old 70- rules
*before* the update, or just be sure to do so before I reboot after the
update?
No idea, I'd expect it to be only needed for the reboot, but I don't
know udev *that* well.
Thanks - I'm sure I'm just being paranoid, but it has helped me to avoid
lots of pain in the past with other major updates on this system over
these last 8+ years.
(I'm not concerned about the cd rule because obviously that won't affect
the system booting, so I can come back and fix this one later if needed)
--
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/
