[Bug 849749] New: 13.1/post-RC2 (via dup) x64 network devices on pcie bus not persistently named: enp3s0 becomes enp6s0 with adding another pcie card?
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c0 Summary: 13.1/post-RC2 (via dup) x64 network devices on pcie bus not persistently named: enp3s0 becomes enp6s0 with adding another pcie card? Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: abittner@abittner.de QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 I am not sure about these new namings of ethernet cards any more with the new kernel or systemd or whoever is in charge here, but an onboard realtek ethernet port was intially already configured as dhcp just fine. then i added another realtek pcie network card later on, and the system then had no working ethernet configuration any more suddenly and the initial onboard chip that used to be named enp3s0 is now being listed as enp6s0 and needed to be set new as dhcp, and the additional pcie slot card (dual nic) is being named as enp4s0 and enp5s0 (no configs set yet) this is odd. am I misunderstand the new naming scheme? Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: current situation with onboard nic and pcie-dualnic from dmesg: [ 5.654437] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 5.655012] r8169 0000:04:00.0 eth0: RTL8168evl/8111evl at 0xffffc90001948000, 00:0a:cd:21:e3:e5, XID 0c900800 IRQ 57 [ 5.655014] r8169 0000:04:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 5.655035] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 5.655360] r8169 0000:05:00.0 eth1: RTL8168evl/8111evl at 0xffffc9000194a000, 00:0a:cd:21:e3:e6, XID 0c900800 IRQ 58 [ 5.655361] r8169 0000:05:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 5.655368] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 5.657199] r8169 0000:06:00.0 eth2: RTL8168g/8111g at 0xffffc90001974000, d8:50:e6:4c:08:d4, XID 0c000800 IRQ 59 [ 5.657202] r8169 0000:06:00.0 eth2: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 5.706037] systemd-udevd[309]: renamed network interface eth2 to enp6s0 [ 6.409314] systemd-udevd[306]: renamed network interface eth0 to enp4s0 [ 6.415252] systemd-udevd[307]: renamed network interface eth1 to enp5s0 but my sysconfig/network/ directory shows the old config file and the new config file for actually the same onboard nic device, which is odd. My understand and the documentation said that these same physical network devices and chips and ports should retain their names and not get confused and mixed and renamed back and forth any more. so what is wrong here? the onboard nic config file that got created and named initially until there was no additional pcie dual-nic card installed: -rw------- 1 root root 200 Nov 10 00:43 ifcfg-enp3s0 content: OOTPROTO='dhcp' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' ifcfg-enp3s0 lines 1-11/11 (END) the newer config file now for the same onboard nic but now under a different name and needing to be set again: -rw-r--r-- 1 root root 200 Nov 10 12:17 ifcfg-enp6s0 content: BOOTPROTO='dhcp' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' ifcfg-enp6s0 lines 1-11/11 (END) The pcie dual-nic card is constructed via a pci bridge as far as I understand and see on the PCB of that card: lspci: 02:00.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev aa) 03:01.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev aa) 03:02.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev aa) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) 02:00.0 PCI bridge [0604]: PLX Technology, Inc. Device [10b5:8603] (rev aa) 03:01.0 PCI bridge [0604]: PLX Technology, Inc. Device [10b5:8603] (rev aa) 03:02.0 PCI bridge [0604]: PLX Technology, Inc. Device [10b5:8603] (rev aa) 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06) 05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06) 06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c) +-15.0-[02-05]----00.0-[03-05]--+-01.0-[04]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller | \-02.0-[05]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller +-15.1-[06]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c1 --- Comment #1 from andreas bittner <abittner@abittner.de> 2013-11-10 12:12:49 UTC --- situation when only booting with the onboard realtek network chip: dmesg: [ 5.298581] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 5.300867] r8169 0000:03:00.0 eth0: RTL8168g/8111g at 0xffffc90001970000, d8:50:e6:4c:08:d4, XID 0c000800 IRQ 53 [ 5.300870] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 5.366436] systemd-udevd[324]: renamed network interface eth0 to enp3s0 lspci_ 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c) Subsystem: ASUSTeK Computer Inc. Device [1043:8554] Kernel driver in use: r8169 Kernel modules: r8169 +-15.1-[03]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c zhang jiajun <jzhang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jzhang@suse.com AssignedTo|bnc-team-screening@forge.pr |mvidner@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c Martin Vidner <mvidner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|jzhang@suse.com | AssignedTo|mvidner@suse.com |mfilka@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c2 Michal Filka <mfilka@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|mfilka@suse.com |rmilasan@suse.com --- Comment #2 from Michal Filka <mfilka@suse.com> 2013-12-16 10:29:11 UTC --- I think this has nothing to do with yast. Yast only creates configs and these configs are based on system state in the time of creation. AFAIK, these names should be persistent across system reboots, I hardly doubt that hw changes (adding) are completely supported too. udev generates these names -> reassigned to udev maintainer. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c3 Robert Milasan <rmilasan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |jslaby@suse.com --- Comment #3 from Robert Milasan <rmilasan@suse.com> 2013-12-16 12:05:14 UTC --- Sorry, but this is not udev, looks like how the nic's are assign by the kernel or hardware. Jiri, can you give an idea of whats going on? I believe is the kernel or hardware, but not really sure. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c4 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby@suse.com InfoProvider|jslaby@suse.com |abittner@abittner.de --- Comment #4 from Jiri Slaby <jslaby@suse.com> 2014-01-09 09:04:36 UTC --- (In reply to comment #3)
Sorry, but this is not udev, looks like how the nic's are assign by the kernel or hardware.
But the kernel gives it proper names eth0, eth1, eth2... It's udev, who renames it persistently to names as we can see. So there is an issue in udev which prevents from doing so. Could you attach content of your /etc/udev/rules.d/*persistent-net*? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c5 --- Comment #5 from Robert Milasan <rmilasan@suse.com> 2014-01-09 09:44:21 UTC --- Sorry, I think I jumped the gun, but this is still a kernel or hardware issue. The new naming is based on what slot and bus the card is on, as you can see enp3s0 (based on what udev finds in /sys/class/net/enp3s0 for example). The fact that you add or remove a physical device shouldn't that much affect the naming, but maybe your hardware does it for whatever reason (changing the bus and slot I mean). This is why I said before that is not udev, not because of persistent names or something like that: the rule doing the naming: NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}" NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}" NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}" robert@viper:~> udevadm test-builtin net_id /sys/class/net/enp0s25 calling: test-builtin === trie on-disk === tool version: 208 file size: 5968358 bytes header size 80 bytes strings 1302262 bytes nodes 4666016 bytes load module index ID_NET_NAME_MAC=enx180373dbc331 ID_OUI_FROM_DATABASE=Dell Inc ID_NET_NAME_PATH=enp0s25 This is from net_id builtin command from udev: * * Type of names: * o<index> -- on-board device index number * s<slot>[f<function>][d<dev_id>] -- hotplug slot index number * x<MAC> -- MAC address * [P<domain>]p<bus>s<slot>[f<function>][d<dev_id>] * -- PCI geographical location * [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>] * -- USB port number chain I will try to take a better look at net_id, maybe there is something wrong in it, but please also do the following: readlink -f /sys/class/net/enp6s0 readlink -f /sys/class/net/enp5s0 readlink -f /sys/class/net/enp4s0 and attach the output to the bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c6 --- Comment #6 from Jiri Slaby <jslaby@suse.com> 2014-01-09 10:40:12 UTC --- (In reply to comment #5)
Sorry, I think I jumped the gun, but this is still a kernel or hardware issue. The new naming is based on what slot and bus the card is on, as you can see enp3s0 (based on what udev finds in /sys/class/net/enp3s0 for example).
Nobody guarantees the PCI port and slot to be stable. For USB, these numbers are unstable even for re-connections. If the naming is based on that, the naming is bogus. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c7 --- Comment #7 from Robert Milasan <rmilasan@suse.com> 2014-01-09 10:58:46 UTC --- It might be bogus, but I haven't come up with this on myself. I agree if this happens to users all the time, it will be a pain in the butt. Anyway, it is still possible to manually generate a persistent rule which might be a bit more stable for this users. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c8 --- Comment #8 from Jiri Slaby <jslaby@suse.com> 2014-01-09 11:09:43 UTC --- Ok, the systemd folks tried to re-invent the wheel. And they failed like in every other case. What's wrong with MAC-address-based persistent naming? (And use that en* naming as a fall-back...) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c9 Ralf Friedl <Ralf.Friedl@online.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |Ralf.Friedl@online.de InfoProvider|abittner@abittner.de | --- Comment #9 from Ralf Friedl <Ralf.Friedl@online.de> 2014-03-10 15:09:50 UTC --- (In reply to comment #8)
Ok, the systemd folks tried to re-invent the wheel. And they failed like in every other case. ACK What's wrong with MAC-address-based persistent naming? (And use that en* naming as a fall-back...)
I just want to add that I have exactly the same problem. I added an extra network card, and these stupid interface names just changed. Before this, for many years I could be sure that once assigned, the interface names would stay the same, using /etc/udev/rules.d/70-persistent-net.rules. Now I add a new card and all the configuration is messed up. In case the needinfo refers to the readlink commands above, here the output from my system: Mainboard only: /sys/devices/pci0000:00/0000:00:06.0/0000:03:00.0/net/enp3s0 Mainboard and external card, mainboard is now enp4s0: /sys/devices/pci0000:00/0000:00:05.0/0000:03:00.0/net/enp3s0 /sys/devices/pci0000:00/0000:00:06.0/0000:04:00.0/net/enp4s0 Also lspci: Mainboard only: 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 04:06.0 Network controller: AVM GmbH Fritz!PCI v2.0 ISDN (rev 02) Mainboard and external card, mainboard is now enp4s0: 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 05:06.0 Network controller: AVM GmbH Fritz!PCI v2.0 ISDN (rev 02) As you can see, the number is just an enumeration, so the naming is just as unpredictable as before, but with more confusing names. Who wants to remember on a machine with only one interface, whether on a particular machine it is called enp3s0 or enp5s1, when before you could be sure the name was eth0? And for machines with multiple interfaces, we had 70-persistent-net.rules and a network name once assigned never changed. So this change makes nothing better and everything worse. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c10 Robert Milasan <rmilasan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P4 - Low Status|NEW |ASSIGNED --- Comment #10 from Robert Milasan <rmilasan@suse.com> 2014-03-11 11:02:07 UTC --- This issue seems to be due to hardware, but also because of the implementation currently available in systemd/udev. Basically, that upstream said, is that the BIOS or hardware in general does this and it shouldn't (cheap hardware, broken firmware, broken BIOS, etc). I don't exactly agree with an implementation that can break at any time due to hardware, but I wasn't the one casting votes for this. At the moment, a user can create a persistent rule, based on the mac addresses of the nic's and it would work quite OK, but the setup must be done manually. I, honestly, not sure what direction to take here, bring back something that is not supported, but works for normal users (doesn't work with virtual functions, igb and ixgbe modules, breaks everything) or leave it alone and close it as UPSTREAM. There is a workaround for this issue, meaning manually create the persistent rule, but some people may not like the idea of having to do some extra work. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c11 --- Comment #11 from Ralf Friedl <Ralf.Friedl@online.de> 2014-03-11 11:44:40 UTC --- (In reply to comment #10)
This issue seems to be due to hardware, but also because of the implementation currently available in systemd/udev.
Basically, that upstream said, is that the BIOS or hardware in general does this and it shouldn't (cheap hardware, broken firmware, broken BIOS, etc). The board is from Gigabyte, so not exactly a cheap one.
Is there a specification that says that the assigned numbers have to be the same across reboots? If not, then it is not cheap/broken hardware, but a flawed assumption in the software.
I, honestly, not sure what direction to take here Can you tell me a single advantage of the new system, compared to the previous state of opensuse? The previous state was not to let the kernel assign random numbers, but to make once assigned interface names permanent. Exactly what this change promised to bring, and exactly what it took away. And before, I had the predictable name eth0 for the common case, a machine with only one network interface, instead of enp3s0 or whatever. Even if this name was persistent, it would still be worse than before.
There is a workaround for this issue, meaning manually create the persistent rule, but some people may not like the idea of having to do some extra work.
Great, extra work for things that used to work automatically. If you want to leave it that way, at least make the input field for the interface name in yast (text version) longer (yast lan -> edit -> hardware -> udev rules -> change -> Device name). The field has only 5 characters, and first and last are used as indicators that the content is longer. It looks like this: "-p0s-" -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c12 --- Comment #12 from Robert Milasan <rmilasan@suse.com> 2014-03-11 12:03:09 UTC --- (In reply to comment #11)
(In reply to comment #10)
This issue seems to be due to hardware, but also because of the implementation currently available in systemd/udev.
Basically, that upstream said, is that the BIOS or hardware in general does this and it shouldn't (cheap hardware, broken firmware, broken BIOS, etc). The board is from Gigabyte, so not exactly a cheap one.
Gigabyte doesn't come across expensive motherboard. I understand you payed some good money for it, but it's not what I would consider expensive motherboard (it's not the point, just part of the idea).
Is there a specification that says that the assigned numbers have to be the same across reboots? If not, then it is not cheap/broken hardware, but a flawed assumption in the software.
I, honestly, not sure what direction to take here Can you tell me a single advantage of the new system, compared to the previous state of opensuse? The previous state was not to let the kernel assign random numbers, but to make once assigned interface names permanent. Exactly what this change promised to bring, and exactly what it took away. And before, I had the predictable name eth0 for the common case, a machine with only one network interface, instead of enp3s0 or whatever. Even if this name was persistent, it would still be worse than before.
Logically, the predictable name should be 100% stable across reboots and you can't have 2 nic's named the same, like ever, due to the construction of the actual naming. That would be the idea, now that is doesn't always work well, thats something else. In the past due to the naming there were collisions, especially if the user would use virtual function in the already named modules or supported nic's, which usually end-up that the virtual network adapters were called ethX, but the physical adapters end-up to be called renameX (this was due to the persistent rule which had already names setup for the physical adapters, but for the virtual ones, no). Also the virtual adapters can't have a persistent name due to random mac addresses (each reboot, new mac address), so you couldn't actually handle them.
There is a workaround for this issue, meaning manually create the persistent rule, but some people may not like the idea of having to do some extra work.
Great, extra work for things that used to work automatically.
If you want to leave it that way, at least make the input field for the interface name in yast (text version) longer (yast lan -> edit -> hardware -> udev rules -> change -> Device name). The field has only 5 characters, and first and last are used as indicators that the content is longer. It looks like this: "-p0s-"
Yast has nothing to do with systemd/udev, thats Yast people. The kernel names the devices ethX, not a rule, previously we had something called write_net_rules which would generate a persistent rule, which in terms would name the devices ethX (which ever came first got eth0, then eth1, etc). The new names are based on some logic (which doesn't seem to work well) en (ethernet adapter) pX (port number, based on the location on the motherboard) sX (slot number, based on the location on the motherboard) So you got: enp0s3, means ethernet adapter on port(bus) 0 and slot 3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c13 --- Comment #13 from Ralf Friedl <Ralf.Friedl@online.de> 2014-03-12 15:56:22 UTC --- (In reply to comment #12)
In the past due to the naming there were collisions, especially if the user would use virtual function in the already named modules or supported nic's, which usually end-up that the virtual network adapters were called ethX, but the physical adapters end-up to be called renameX (this was due to the persistent rule which had already names setup for the physical adapters, but for the virtual ones, no). Also the virtual adapters can't have a persistent name due to random mac addresses (each reboot, new mac address), so you couldn't actually handle them. I haven't needed those so far, but I would imagine that virtual adapters based in the physical adapters should only be created after the physical adapters have appeared and been renamed. Also I don't know know what kind of persistence is desired if the MAC is generated at random and not saved.
If you want to leave it that way, at least make the input field for the interface name in yast (text version) longer (yast lan -> edit -> hardware -> udev rules -> change -> Device name). The field has only 5 characters, and first and last are used as indicators that the content is longer. It looks like this: "-p0s-"
Yast has nothing to do with systemd/udev, thats Yast people. Can you inform them or do you want me to open another ticket for that?
The kernel names the devices ethX, not a rule, previously we had something called write_net_rules which would generate a persistent rule, which in terms would name the devices ethX (which ever came first got eth0, then eth1, etc). I know, the actual numbers could be different from these that the kernel assigned, but after the first boot the assigned number would be written to the persistent rule, and the name would not change later, ever.
The new names are based on some logic (which doesn't seem to work well) I understand the logic, but I don't usually care how the motherboard assigns numbers to the slots. We also use /dev/sda and not/dev/sdp3s0. But I know, there are the /dev/disk/by* symlinks, and you can't use symlinks for network names.
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c14 --- Comment #14 from Robert Milasan <rmilasan@suse.com> 2014-03-13 08:02:12 UTC --- (In reply to comment #13)
(In reply to comment #12)
In the past due to the naming there were collisions, especially if the user would use virtual function in the already named modules or supported nic's, which usually end-up that the virtual network adapters were called ethX, but the physical adapters end-up to be called renameX (this was due to the persistent rule which had already names setup for the physical adapters, but for the virtual ones, no). Also the virtual adapters can't have a persistent name due to random mac addresses (each reboot, new mac address), so you couldn't actually handle them. I haven't needed those so far, but I would imagine that virtual adapters based in the physical adapters should only be created after the physical adapters have appeared and been renamed. Also I don't know know what kind of persistence is desired if the MAC is generated at random and not saved.
No, the kernel doesn't do the naming of physical or/and virtual nic's on a normal level, meaning is random, which ever comes first gets eth0 and so on. That is why the persistent setup has been implemented in udev. If you have for example 2 nic's, eth0 and eth1, no persistent setup/rules, eth0 can be eth1 and vice-versa, every time you reboot. This means that which ever comes first will get the first name. The kernel doesn't care about the name, it just gives on basis of first come first served. Virtual nic's MAC addresses are random, so persistent naming can't be done, as there is no persistent MAC address at reboot.
If you want to leave it that way, at least make the input field for the interface name in yast (text version) longer (yast lan -> edit -> hardware -> udev rules -> change -> Device name). The field has only 5 characters, and first and last are used as indicators that the content is longer. It looks like this: "-p0s-"
Yast has nothing to do with systemd/udev, thats Yast people. Can you inform them or do you want me to open another ticket for that?
Yes, that would be the best idea. Open a new bug for Yast people.
The kernel names the devices ethX, not a rule, previously we had something called write_net_rules which would generate a persistent rule, which in terms would name the devices ethX (which ever came first got eth0, then eth1, etc). I know, the actual numbers could be different from these that the kernel assigned, but after the first boot the assigned number would be written to the persistent rule, and the name would not change later, ever.
That is the idea for persistent rule as the kernel doesn't keep the same name for the same nic. Problem is we where naming the same way as the kernel the nic's and this is how predictable names where born, never name a nic like ethX, makes it more stable (the concept is good, the practical side, it's a different story).
The new names are based on some logic (which doesn't seem to work well) I understand the logic, but I don't usually care how the motherboard assigns numbers to the slots. We also use /dev/sda and not/dev/sdp3s0. But I know, there are the /dev/disk/by* symlinks, and you can't use symlinks for network names.
I do not argue with you about this and I do understand that is a problem, but there is a workaround for those who have this kind of issue. Also this is how upstream and most other distros are doing it now a days, so to be a bit consistent with the Linux world, we need to keep it as much as possible the same. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c15 Robert Milasan <rmilasan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |UPSTREAM --- Comment #15 from Robert Milasan <rmilasan@suse.com> 2014-06-06 08:12:42 UTC --- Setting bug to RESOLVED/UPSTREAM. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com