[opensuse] Setting up network devices with YaST

Marc Chamberlin

20 Mar 2013 20 Mar '13

18:07

I have had this happen before, but unfortunately I don't remember how I solved it.... I am installing openSuSE 12.3 on a gateway server with 2 NICs. Somehow, somewhere openSuSE/YaST gets the device names I want to assign to each NIC (eth0 and eth1) backwards, and I need to reverse the assignments. I have tried the obvious approach of going in to YaST -> Network Devices -> NetworkSettings -> Overview, select the NIC card and edit it, go to the Hardware tab and change the device names. If I try to simply change, for example, eth0 to eth1, it confuses YaST when it sees two devices with the same name, in this case 2 eth1 devices. (even though I plan to change the other NIC's device name shortly.) So I tried a different approach, change eth0 to eth2, eth1 to eth0, and then eth2 to eth1. On the surface that seems to work, according to YaST, but the network remains unusable and from logs and other indications I believe that YaST is not doing a thorough job of changing device names where necessary. I can see log messages showing communication attempts that is going on over the network which is indicating that communication attempts is still being done via the wrong NIC/device. (Wireshark confirms this also.) A question I might ask, if I delete all the network devices in YaST, and start over with setting them up, YaST by default assigns the device names to each NIC but as I said opposite to what I want. Where/how does YaST get this initial assignment of device names for each NIC? Is there somewhere I could go, underneath, and reconfigure manually the device names? (I have done some hunting around via grep, searched all through /etc for example, and no joy finding a magic config file....) If not, then how do I switch the device names assigned to each NIC, if YaST cannot do it? Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

Robert Schweikert

20 Mar 20 Mar

18:20

On 03/20/2013 02:07 PM, Marc Chamberlin wrote:

...

I have had this happen before, but unfortunately I don't remember how I solved it.... I am installing openSuSE 12.3 on a gateway server with 2 NICs. Somehow, somewhere openSuSE/YaST gets the device names I want to assign to each NIC (eth0 and eth1) backwards, and I need to reverse the assignments. I have tried the obvious approach of going in to YaST -> Network Devices -> NetworkSettings -> Overview, select the NIC card and edit it, go to the Hardware tab and change the device names. If I try to simply change, for example, eth0 to eth1, it confuses YaST when it sees two devices with the same name, in this case 2 eth1 devices. (even though I plan to change the other NIC's device name shortly.) So I tried a different approach, change eth0 to eth2, eth1 to eth0, and then eth2 to eth1. On the surface that seems to work, according to YaST, but the network remains unusable and from logs and other indications I believe that YaST is not doing a thorough job of changing device names where necessary. I can see log messages showing communication attempts that is going on over the network which is indicating that communication attempts is still being done via the wrong NIC/device. (Wireshark confirms this also.)

A question I might ask, if I delete all the network devices in YaST, and start over with setting them up, YaST by default assigns the device names to each NIC but as I said opposite to what I want. Where/how does YaST get this initial assignment of device names for each NIC? Is there somewhere I could go, underneath, and reconfigure manually the device names? (I have done some hunting around via grep, searched all through /etc for example, and no joy finding a magic config file....)

Devices and their names are handled by the kernel via udev. YaST gets its information from udev and displays the "truth", i.e. the way the kernel handles the devices. If you need to modify this you will need to create a udev rule that meets your needs. Then place the the rules in /etc/udev/rules.d. Network overrides are stored in the rule: 70-persistent-net.rules HTH, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

18:38

Robert Schweikert wrote:

...

On 03/20/2013 02:07 PM, Marc Chamberlin wrote:

...
I have had this happen before, but unfortunately I don't remember how I solved it.... I am installing openSuSE 12.3 on a gateway server with 2 NICs. Somehow, somewhere openSuSE/YaST gets the device names I want to assign to each NIC (eth0 and eth1) backwards, and I need to reverse the assignments. I have tried the obvious approach of going in to YaST -> Network Devices -> NetworkSettings -> Overview, select the NIC card and edit it, go to the Hardware tab and change the device names. If I try to simply change, for example, eth0 to eth1, it confuses YaST when it sees two devices with the same name, in this case 2 eth1 devices. (even though I plan to change the other NIC's device name shortly.) So I tried a different approach, change eth0 to eth2, eth1 to eth0, and then eth2 to eth1. On the surface that seems to work, according to YaST, but the network remains unusable and from logs and other indications I believe that YaST is not doing a thorough job of changing device names where necessary. I can see log messages showing communication attempts that is going on over the network which is indicating that communication attempts is still being done via the wrong NIC/device. (Wireshark confirms this also.)

A question I might ask, if I delete all the network devices in YaST, and start over with setting them up, YaST by default assigns the device names to each NIC but as I said opposite to what I want. Where/how does YaST get this initial assignment of device names for each NIC? Is there somewhere I could go, underneath, and reconfigure manually the device names? (I have done some hunting around via grep, searched all through /etc for example, and no joy finding a magic config file....)

Devices and their names are handled by the kernel via udev. YaST gets its information from udev and displays the "truth", i.e. the way the kernel handles the devices.

If you need to modify this you will need to create a udev rule that meets your needs. Then place the the rules in /etc/udev/rules.d. Network overrides are stored in the rule:

70-persistent-net.rules

Hmm, something changed in 12.3, see https://bugzilla.novell.com/show_bug.cgi?id=809843 -- Per Jessen, Zürich (7.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin

20:56

On 3/20/2013 11:38 AM, Per Jessen wrote:

...

Robert Schweikert wrote:

...
On 03/20/2013 02:07 PM, Marc Chamberlin wrote:

...
I have had this happen before, but unfortunately I don't remember how I solved it.... I am installing openSuSE 12.3 on a gateway server with 2 NICs. Somehow, somewhere openSuSE/YaST gets the device names I want to assign to each NIC (eth0 and eth1) backwards, and I need to reverse the assignments. I have tried the obvious approach of going in to YaST -> Network Devices -> NetworkSettings -> Overview, select the NIC card and edit it, go to the Hardware tab and change the device names. If I try to simply change, for example, eth0 to eth1, it confuses YaST when it sees two devices with the same name, in this case 2 eth1 devices. (even though I plan to change the other NIC's device name shortly.) So I tried a different approach, change eth0 to eth2, eth1 to eth0, and then eth2 to eth1. On the surface that seems to work, according to YaST, but the network remains unusable and from logs and other indications I believe that YaST is not doing a thorough job of changing device names where necessary. I can see log messages showing communication attempts that is going on over the network which is indicating that communication attempts is still being done via the wrong NIC/device. (Wireshark confirms this also.)

A question I might ask, if I delete all the network devices in YaST, and start over with setting them up, YaST by default assigns the device names to each NIC but as I said opposite to what I want. Where/how does YaST get this initial assignment of device names for each NIC? Is there somewhere I could go, underneath, and reconfigure manually the device names? (I have done some hunting around via grep, searched all through /etc for example, and no joy finding a magic config file....) Devices and their names are handled by the kernel via udev. YaST gets its information from udev and displays the "truth", i.e. the way the kernel handles the devices.

If you need to modify this you will need to create a udev rule that meets your needs. Then place the the rules in /etc/udev/rules.d. Network overrides are stored in the rule:

70-persistent-net.rules

Hmm, something changed in 12.3, see https://bugzilla.novell.com/show_bug.cgi?id=809843

Oh boy! Thanks Per Jessen for the pointer to that bug report. Looks like the guru's are on top of it and chasing this problem down. My question now becomes this - For those of us with an impaired network under 12.3 how do we get the fix for this bug when it becomes available? Do we have to download a new ISO file/DVD for openSuSE12.3 and reinstall from scratch? Hopefully this fix will be available soon, (how will I know?) and again for the record I wish the openSuSE designers would give some thought on how we are suppose to set our systems up so we can regress back to a previous version of openSuSE when upgades go wrong or take a long time to complete.... Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Istvan Gabor

21 Mar 21 Mar

10:50

2013. március 20. 21:56 napon Marc Chamberlin írta:

...

On 3/20/2013 11:38 AM, Per Jessen wrote:

...
Robert Schweikert wrote:

...
On 03/20/2013 02:07 PM, Marc Chamberlin wrote:

...
I have had this happen before, but unfortunately I don't remember how I solved it.... I am installing openSuSE 12.3 on a gateway server with 2 NICs. Somehow, somewhere openSuSE/YaST gets the device names I want to assign to each NIC (eth0 and eth1) backwards, and I need to reverse the assignments. I have tried the obvious approach of going in to YaST -> Network Devices -> NetworkSettings -> Overview, select the NIC card and edit it, go to the Hardware tab and change the device names. If I try to simply change, for example, eth0 to eth1, it confuses YaST when it sees two devices with the same name, in this case 2 eth1 devices. (even though I plan to change the other NIC's device name shortly.) So I tried a different approach, change eth0 to eth2, eth1 to eth0, and then eth2 to eth1. On the surface that seems to work, according to YaST, but the network remains unusable and from logs and other indications I believe that YaST is not doing a thorough job of changing device names where necessary. I can see log messages showing communication attempts that is going on over the network which is indicating that communication attempts is still being done via the wrong NIC/device. (Wireshark confirms this also.)

A question I might ask, if I delete all the network devices in YaST, and start over with setting them up, YaST by default assigns the device names to each NIC but as I said opposite to what I want. Where/how does YaST get this initial assignment of device names for each NIC? Is there somewhere I could go, underneath, and reconfigure manually the device names? (I have done some hunting around via grep, searched all through /etc for example, and no joy finding a magic config file....) Devices and their names are handled by the kernel via udev. YaST gets its information from udev and displays the "truth", i.e. the way the kernel handles the devices.

If you need to modify this you will need to create a udev rule that meets your needs. Then place the the rules in /etc/udev/rules.d. Network overrides are stored in the rule:

70-persistent-net.rules

Hmm, something changed in 12.3, see https://bugzilla.novell.com/show_bug.cgi?id=809843

Oh boy! Thanks Per Jessen for the pointer to that bug report. Looks like the guru's are on top of it and chasing this problem down. My question now becomes this - For those of us with an impaired network under 12.3 how do we get the fix for this bug when it becomes available? Do we have to download a new ISO file/DVD for openSuSE12.3 and reinstall from scratch?

Hopefully this fix will be available soon, (how will I know?) and again for the record I wish the openSuSE designers would give some thought on how we are suppose to set our systems up so we can regress back to a previous version of openSuSE when upgades go wrong or take a long time to complete....

Marc...

Hello: How about this as workaround? Plug out or disable in BIOS your second card, and leave active only the first one. Boot openSUSE, start network config from scratch. Now your first cars should get name eth0. Turn off computer, plug in second card (or activate in BIOS), boot openSUSE, and activate the second card in YaST. As your first card is already activated as eth0, the second card should be named eth1. I am curious if this could be a solution, please write back whether it worked or not. Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin

22 Mar 22 Mar

17:10

...

Hello: How about this as workaround? Plug out or disable in BIOS your second card, and leave active only the first one. Boot openSUSE, start network config from scratch. Now your first cars should get name eth0. Turn off computer, plug in second card (or activate in BIOS), boot openSUSE, and activate the second card in YaST. As your first card is already activated as eth0, the second card should be named eth1. I am curious if this could be a solution, please write back whether it worked or not. Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org Thanks for writing Istvan, unfortunately no joy using your idea. Per Jesson pointed out that there is a bug which is causing the device ID to be randomly assigned to each NIC, so despite the fact that you might be able to get the assignments correct one time does not mean it will stay

On 3/21/2013 3:50 AM, Istvan Gabor wrote: persistent the next time you reboot. And that is what is happening to me, even when I tried your approach and removed one of the NICs, then added it back in later... What is really weird is that YaST may report the device ID's assigned to each NIC one way, while in actual fact what gets transmitted over each NIC may be going in and out of the other one. That means the kernel thinks the device IDs are assigned opposite to what YaST thinks, and YaST apparently does not have the ability to reassign the device ID's correctly. (I tried, and it fails...) Marc.. -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov

17:14

В Fri, 22 Mar 2013 10:10:22 -0700 Marc Chamberlin пишет:

...

Thanks for writing Istvan, unfortunately no joy using your idea. Per Jesson pointed out that there is a bug which is causing the device ID to be randomly assigned to each NIC, so despite the fact that you might be able to get the assignments correct one time does not mean it will stay persistent the next time you reboot.

Update to put back legacy persistent interface names is already submitted. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin

22:59

On 3/22/2013 10:14 AM, Andrey Borzenkov wrote:

...

В Fri, 22 Mar 2013 10:10:22 -0700 Marc Chamberlin пишет:

...
Thanks for writing Istvan, unfortunately no joy using your idea. Per Jesson pointed out that there is a bug which is causing the device ID to be randomly assigned to each NIC, so despite the fact that you might be able to get the assignments correct one time does not mean it will stay persistent the next time you reboot. Update to put back legacy persistent interface names is already submitted. And how does one go about getting this update? Marc...

-- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

23 Mar 23 Mar

00:18

Marc Chamberlin wrote:

...

On 3/22/2013 10:14 AM, Andrey Borzenkov wrote:

...
В Fri, 22 Mar 2013 10:10:22 -0700 Marc Chamberlin пишет:

...
Thanks for writing Istvan, unfortunately no joy using your idea. Per Jesson pointed out that there is a bug which is causing the device ID to be randomly assigned to each NIC, so despite the fact that you might be able to get the assignments correct one time does not mean it will stay persistent the next time you reboot. Update to put back legacy persistent interface names is already submitted. And how does one go about getting this update? Marc...

You ought to be able to manually configure a network interface and then get access to the update repo. -- Per Jessen, Zürich (4.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov

04:12

В Fri, 22 Mar 2013 15:59:32 -0700 Marc Chamberlin пишет:

...

On 3/22/2013 10:14 AM, Andrey Borzenkov wrote:

...
В Fri, 22 Mar 2013 10:10:22 -0700 Marc Chamberlin пишет:

...
Thanks for writing Istvan, unfortunately no joy using your idea. Per Jesson pointed out that there is a bug which is causing the device ID to be randomly assigned to each NIC, so despite the fact that you might be able to get the assignments correct one time does not mean it will stay persistent the next time you reboot. Update to put back legacy persistent interface names is already submitted. And how does one go about getting this update? Marc...

Ehh ... "zypper patch" when it released? If you need it now: https://build.opensuse.org/project/show?project=openSUSE%3AMaintenance%3A147... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin

27 Mar 27 Mar

19:53

...

В Fri, 22 Mar 2013 15:59:32 -0700 Marc Chamberlin пишет:

...
On 3/22/2013 10:14 AM, Andrey Borzenkov wrote:

...
В Fri, 22 Mar 2013 10:10:22 -0700 Marc Chamberlin пишет:

...
Thanks for writing Istvan, unfortunately no joy using your idea. Per Jesson pointed out that there is a bug which is causing the device ID to be randomly assigned to each NIC, so despite the fact that you might be able to get the assignments correct one time does not mean it will stay persistent the next time you reboot. Update to put back legacy persistent interface names is already submitted. And how does one go about getting this update? Marc...

Ehh ... "zypper patch" when it released? If you need it now:

https://build.opensuse.org/project/show?project=openSUSE%3AMaintenance%3A147... Guys - I believe the update came out today. I managed to get my external NIC configured long enough to install it, however still no joy getting my gateway computer to boot up with the network configured correctly, every time. It still behaves randomly, sometimes it works, more often not. I gave up on trying to use YaST to configure the two network cards on my gateway computer however, (it still gets confused when I try to use it to reverse the device names being assigned to each of my NICs) and manually configured the /etc/sysconfig/network/ifcfg-eth* files. Shown below is what I am seeing in log files, the files as they are configured, and the results when I

On 3/22/2013 9:12 PM, Andrey Borzenkov wrote: try to bring up the network manually - From boot.log - [FAILED] Failed to start LSB: Configure network interfaces and set up routing. See 'systemctl status network.service' for details. From systemctl status network.service - systemctl status network.service network.service - LSB: Configure network interfaces and set up routing Loaded: loaded (/etc/init.d/network) Active: failed (Result: exit-code) since Wed, 2013-03-27 11:27:08 PDT; 3min 22s ago Process: 505 ExecStart=/etc/init.d/network start (code=exited, status=7) CGroup: name=systemd:/system/network.service Mar 27 11:27:08 network.name.removed network[505]: 29 28 26 25 24 23 21 20 19 17 16 15 13 12 11 9 8 7 6 4 3 2 0 Mar 27 11:27:08 network.name.removed network[505]: eth0 device: Accton Technology Corporation SMC2-1211TX Mar 27 11:27:08 network.name.removed network[505]: eth0 is down Mar 27 11:27:08 network.name.removed network[505]: ..failed eth0 interface could not be set up until now Mar 27 11:27:08 network.name.removed network[505]: ..failed eth1 device: Intel Corporation 82573V Gigabit Ethernet Con Mar 27 11:27:08 network.name.removed network[505]: eth1 is down Mar 27 11:27:08 network.name.removed network[505]: ..failed eth1 interface could not be set up until now Mar 27 11:27:08 network.name.removed network[505]: ..failedSetting up service network . . . . . . . . . . . . ...failed Mar 27 11:27:08 network.name.removed systemd[1]: Failed to start LSB: Configure network interfaces and set up routing. Mar 27 11:27:08 network.name.removed systemd[1]: Unit network.service entered failed state Contents of /etc/sysconfig/network/ifcfg-eth0 cat ifcfg-eth0 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='169.254.1.100/24' MTU='' NAME='82573V Gigabit Ethernet Controller (Copper)' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' Contents of /etc/sysconfig/network/ifcfg-eth1 cat ifcfg-eth1 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='192.168.10.100/24' MTU='' NAME='SMC2-1211TX' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' Contents of /etc/udev/rules.d/70-persistent-net.rules - cat 70-persistent-net.rules # PCI device 0x8086:0x108b (e1000e) # PCI device 0x1113:0x1211 (8139too) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:29:70:57:84", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:20:7a:8a:fb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" After booting up, the network is NOT working. When I manually bring up eth0 (note: this is trying to assign the wrong NIC to this device name.) - ifup eth0 eth0 device: Accton Technology Corporation SMC2-1211TX (rev 10) redirecting to systemctl try-restart dhcpd When I manually bring up eth1 (note: this is trying to assign the wrong NIC to this device name.) - ifup eth1 eth1 device: Intel Corporation 82573V Gigabit Ethernet Controller (Copper) (rev 03) redirecting to systemctl try-restart dhcpd From ifconfig (you can tell by looking at the MAC addresses that the wrong NIC is assigned the wrong device name and this is inconsistent with 70-persistent-net.rules.) - ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:29:70:57:84 inet addr:169.254.1.100 Bcast:169.254.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4967 errors:0 dropped:0 overruns:0 frame:0 TX packets:350 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:358881 (350.4 Kb) TX bytes:27828 (27.1 Kb) eth1 Link encap:Ethernet HWaddr 00:13:20:7A:8A:FB inet addr:192.168.10.100 Bcast:192.168.10.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:19 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1459 (1.4 Kb) TX bytes:1791 (1.7 Kb) Interrupt:17 Memory:93100000-93120000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:372 errors:0 dropped:0 overruns:0 frame:0 TX packets:372 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:36796 (35.9 Kb) TX bytes:36796 (35.9 Kb) Doing an rcnetwork restart or letting YaST restart the network does not help either. Dunno where else to look or what else I could/should configure, so appreciate any ideas... Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

28 Mar 28 Mar

07:19

Marc Chamberlin wrote:

...

Guys - I believe the update came out today. I managed to get my external NIC configured long enough to install it, however still no joy getting my gateway computer to boot up with the network configured correctly, every time. It still behaves randomly, sometimes it works, more often not. I gave up on trying to use YaST to configure the two network cards on my gateway computer however, (it still gets confused when I try to use it to reverse the device names being assigned to each of my NICs) and manually configured the /etc/sysconfig/network/ifcfg-eth* files. Shown below is what I am seeing in log files, the files as they are configured, and the results when I try to bring up the network manually - [snip] Contents of /etc/sysconfig/network/ifcfg-eth0

cat ifcfg-eth0 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='169.254.1.100/24'

That is a link local address, what are you trying to do here?

...

Contents of /etc/sysconfig/network/ifcfg-eth1

cat ifcfg-eth1 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='192.168.10.100/24' MTU='' NAME='SMC2-1211TX' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no'

Looks good.

...

Contents of /etc/udev/rules.d/70-persistent-net.rules -

cat 70-persistent-net.rules # PCI device 0x8086:0x108b (e1000e) # PCI device 0x1113:0x1211 (8139too) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:29:70:57:84", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:20:7a:8a:fb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Looks good.

...

After booting up, the network is NOT working. When I manually bring up eth0 (note: this is trying to assign the wrong NIC to this device name.) -

ifup eth0 eth0 device: Accton Technology Corporation SMC2-1211TX (rev 10)

Yup, that is weird.

...

When I manually bring up eth1 (note: this is trying to assign the wrong NIC to this device name.) -

ifup eth1 eth1 device: Intel Corporation 82573V Gigabit Ethernet Controller (Copper) (rev 03)

So the devices appear to have been swapped. At least the descriptive tag.

...

redirecting to systemctl try-restart dhcpd

That is also weird, both of your devices have static IP addresses.

...

From ifconfig (you can tell by looking at the MAC addresses that the wrong NIC is assigned the wrong device name and this is inconsistent with 70-persistent-net.rules.) -

Right. I'll probably try out this update myself over Easter, but I suggest you update the bugreport with your results. -- Per Jessen, Zürich (1.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin

17:32

...

[snip] Contents of /etc/sysconfig/network/ifcfg-eth0

cat ifcfg-eth0 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='169.254.1.100/24' That is a link local address, what are you trying to do here? Yep, my gateway computer is at a remote location and is connected to the internet via wireless Motorola Canopy modules. If these should suffer a

On 3/28/2013 12:19 AM, Per Jessen wrote: power failure, or need to be remotely rebooted, they will revert back to using a link local (static) IP address when they come back up. (So far I have been unable to change this behavior and get them to come up with a normal private IP network address.) The Canopies are on towers, difficult to get easy/quick access to in order to change their IP addresses to some other private IP address, so instead I just take the path of least resistance and have my gateway computer also use a link local address in order to be on the same network as the Canopies. (This allows me to configure the Canopies from the gateway computer as well.) At the far end of these wireless links, there is a router which is configured to use our real internet address that joins with the link local network. [snip]

...

So the devices appear to have been swapped. At least the descriptive tag.

...
redirecting to systemctl try-restart dhcpd That is also weird, both of your devices have static IP addresses. The number of systems/devices on the external network is small and does not change, nor can the Motorola Canopies be configured to use a dhcp server, so all devices/systems on it are given fixed static link local IP addresses. The internal NIC probably could be assigned an IP address by a dhcp server, but I haven't bothered to do so... This is convenient for the small internal network I have on this end.

...
From ifconfig (you can tell by looking at the MAC addresses that the wrong NIC is assigned the wrong device name and this is inconsistent with 70-persistent-net.rules.) - Right. I'll probably try out this update myself over Easter, but I suggest you update the bugreport with your results. Ok, will do, thanks, and will anxiously await hearing further.... Marc..

-- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin

20 Mar 20 Mar

19:32

On 3/20/2013 11:20 AM, Robert Schweikert wrote:

...

On 03/20/2013 02:07 PM, Marc Chamberlin wrote:

...
I have had this happen before, but unfortunately I don't remember how I solved it.... I am installing openSuSE 12.3 on a gateway server with 2 NICs. Somehow, somewhere openSuSE/YaST gets the device names I want to assign to each NIC (eth0 and eth1) backwards, and I need to reverse the assignments. I have tried the obvious approach of going in to YaST -> Network Devices -> NetworkSettings -> Overview, select the NIC card and edit it, go to the Hardware tab and change the device names. If I try to simply change, for example, eth0 to eth1, it confuses YaST when it sees two devices with the same name, in this case 2 eth1 devices. (even though I plan to change the other NIC's device name shortly.) So I tried a different approach, change eth0 to eth2, eth1 to eth0, and then eth2 to eth1. On the surface that seems to work, according to YaST, but the network remains unusable and from logs and other indications I believe that YaST is not doing a thorough job of changing device names where necessary. I can see log messages showing communication attempts that is going on over the network which is indicating that communication attempts is still being done via the wrong NIC/device. (Wireshark confirms this also.)

A question I might ask, if I delete all the network devices in YaST, and start over with setting them up, YaST by default assigns the device names to each NIC but as I said opposite to what I want. Where/how does YaST get this initial assignment of device names for each NIC? Is there somewhere I could go, underneath, and reconfigure manually the device names? (I have done some hunting around via grep, searched all through /etc for example, and no joy finding a magic config file....)

Devices and their names are handled by the kernel via udev. YaST gets its information from udev and displays the "truth", i.e. the way the kernel handles the devices.

If you need to modify this you will need to create a udev rule that meets your needs. Then place the the rules in /etc/udev/rules.d. Network overrides are stored in the rule:

70-persistent-net.rules

HTH, Robert

Thanks Robert for your reply, but no joy! I found the file 70-persistent-net.rules and it had two entries in it for the 2 NICs, and as expected the device names were backwards. So I reversed them and this is what this file now looks like - cat 70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:20:7a:8a:fb", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:29:70:57:84", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" However, when I bring up YaST and it's Network Settings, the NIC card with the MAC address of 00:13:20:7a:8a:fb is still showing up with the device name of eth1 by default. I even tried rebooting after making this change, and still no joy... Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

23 Mar 23 Mar

02:01

El 20/03/13 16:32, Marc Chamberlin escribió:

...

...
Thanks Robert for your reply, but no joy!

This issue is known and there will be a permanent fix in the next openSUSE release. however, interfaces will change their usual known names. see http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface... In the meanwhile a workaround will help in most cases. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward

11:25

Cristian Rodríguez said the following on 03/22/2013 10:01 PM:

...

El 20/03/13 16:32, Marc Chamberlin escribió:

...
...
Thanks Robert for your reply, but no joy!

This issue is known and there will be a permanent fix in the next openSUSE release. however, interfaces will change their usual known names.

ARGH! You mean 13.1 ? It's things like this that drive people to Fedora, or *shock* *horror* Ubuntu! -- This isn't life in the fast lane, it's life in the oncoming traffic. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

12:58

Anton Aylward wrote:

...

Cristian Rodríguez said the following on 03/22/2013 10:01 PM:

...
El 20/03/13 16:32, Marc Chamberlin escribió:

...
...
Thanks Robert for your reply, but no joy!

This issue is known and there will be a permanent fix in the next openSUSE release. however, interfaces will change their usual known names.

ARGH!

You mean 13.1 ?

It's things like this that drive people to Fedora, or *shock* *horror* Ubuntu!

We need to work out a way of letting people optionally keep the old names. Without that, for many people, it'll be impossible to upgrade because so many things are tied to the network interface name (nagios, snmp for instance). -- Per Jessen, Zürich (7.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

16:39

On 03/23/2013 09:58 AM, Per Jessen wrote:

...

Anton Aylward wrote:

...
Cristian Rodríguez said the following on 03/22/2013 10:01 PM:

...
El 20/03/13 16:32, Marc Chamberlin escribió:

...
...
Thanks Robert for your reply, but no joy!

This issue is known and there will be a permanent fix in the next openSUSE release. however, interfaces will change their usual known names.

ARGH!

You mean 13.1 ?

It's things like this that drive people to Fedora, or *shock* *horror* Ubuntu!

We need to work out a way of letting people optionally keep the old names. Without that, for many people, it'll be impossible to upgrade because so many things are tied to the network interface name (nagios, snmp for instance).

I never said this rules should apply to existent installations, but new ones. ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules disables it However bugs about interface naming should also go to /dev/null in the "disabled" case. :P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

24 Mar 24 Mar

10:10

Cristian Rodríguez wrote:

...

On 03/23/2013 09:58 AM, Per Jessen wrote:

...
Anton Aylward wrote:

...
Cristian Rodríguez said the following on 03/22/2013 10:01 PM:

...
El 20/03/13 16:32, Marc Chamberlin escribió:

...
...
Thanks Robert for your reply, but no joy!

This issue is known and there will be a permanent fix in the next openSUSE release. however, interfaces will change their usual known names.

ARGH!

You mean 13.1 ?

It's things like this that drive people to Fedora, or *shock* *horror* Ubuntu!

We need to work out a way of letting people optionally keep the old names. Without that, for many people, it'll be impossible to upgrade because so many things are tied to the network interface name (nagios, snmp for instance).

I never said this rules should apply to existent installations, but new ones.

The problem remains the same for new ones, though. Anyway, as long we don't forcibly change network device names for people, that's good enough for me.

...

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

disables it

However bugs about interface naming should also go to /dev/null in the "disabled" case. :P

This is the kind of attitude that makes people go look for another distro, IMHO. -- Per Jessen, Zürich (2.6°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

12:03

Per Jessen wrote:

...

Cristian Rodríguez wrote:

...
On 03/23/2013 09:58 AM, Per Jessen wrote:

...
Anton Aylward wrote:

...
Cristian Rodríguez said the following on 03/22/2013 10:01 PM:

...
El 20/03/13 16:32, Marc Chamberlin escribió:

...
> Thanks Robert for your reply, but no joy!

This issue is known and there will be a permanent fix in the next openSUSE release. however, interfaces will change their usual known names.

ARGH!

You mean 13.1 ?

It's things like this that drive people to Fedora, or *shock* *horror* Ubuntu!

We need to work out a way of letting people optionally keep the old names. Without that, for many people, it'll be impossible to upgrade because so many things are tied to the network interface name (nagios, snmp for instance).

I never said this rules should apply to existent installations, but new ones.

The problem remains the same for new ones, though. Anyway, as long we don't forcibly change network device names for people, that's good enough for me.

...
ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

disables it

However bugs about interface naming should also go to /dev/null in the "disabled" case. :P

This is the kind of attitude that makes people go look for another distro, IMHO.

Sorry, I overlooked your smiley ... need glasses. -- Per Jessen, Zürich (2.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

15:55

On 03/24/2013 09:03 AM, Per Jessen wrote:

...

Per Jessen wrote:

...

...
...
However bugs about interface naming should also go to /dev/null in the "disabled" case. :P

This is the kind of attitude that makes people go look for another distro, IMHO.

Sorry, I overlooked your smiley ... need glasses.

Im actually serious, if - a solution is provided but requires you to let udev rename interfaces. - then bugs about the old "unpredictable interface names " should be marked as WONTFIX. - People not liking the solution is not the fault of the solution really. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin

17:53

On 3/24/2013 8:55 AM, Cristian Rodríguez wrote:

...

On 03/24/2013 09:03 AM, Per Jessen wrote:

...
Per Jessen wrote:

...
...
...
However bugs about interface naming should also go to /dev/null in the "disabled" case. :P

This is the kind of attitude that makes people go look for another distro, IMHO.

Sorry, I overlooked your smiley ... need glasses.

Im actually serious, if

- a solution is provided but requires you to let udev rename interfaces.

- then bugs about the old "unpredictable interface names " should be marked as WONTFIX.

- People not liking the solution is not the fault of the solution really.

Cristian - Speaking from the perspective of someone who has to manage and upgrade openSuSE systems, it seems to me that this transition to a new device naming scheme is pretty significant and being handled in a somewhat roughshod fashion. I suspect there are a lot of services, applications and tools which are very dependent on the device interface name and any sort of a change is very likely to break many of them. Case in point is this removal of the persistence mechanism for giving/maintaining device names to NICs. In openSuSE 12.3, it's sudden disappearance broke YaST and my ability to use it to set up a gateway system. Such changes should be more orderly, done gradually over a couple of releases, defaulting at first to the continued usage of the old (even if buggy) method(s). At first simply issue a warning message to mark that the old approach as being deprecated. Even better is to pass along with this warning, information on how to move to the new mechanism(s) so that it can be tested and time given to the developers of all those other applications, services etc., to adapt to the new change(s). And then finally switching to the new method as the default. IMHO this transition is being done too rapidly, especially considering the significance of its impact, and not enough time being given to work out the kinks that are likely to occur... Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

19:10

El 24/03/13 14:53, Marc Chamberlin escribió:

...

I suspect there are a lot of services,

...

applications and tools which are very dependent on the device interface name and any sort of a change is very likely to break many of them.

Yes, and that's why the rules must apply only to new installations. Case

...

in point is this removal of the persistence mechanism for giving/maintaining device names to NICs. In openSuSE 12.3, it's sudden disappearance broke YaST and my ability to use it to set up a gateway system.

Well, it was removed from udev upstream, because it did not work.

...

Such changes should be more orderly, done gradually over a couple of releases, defaulting at first to the continued usage of the old (even if buggy) method(s).

Such change will run in 13.1 , not "between a couple of releases".. you are asking for an approach that will pose a burden on mainteniance and will in practice make things worst, not better.

...

Even better is to pass along with this warning, information on how to move to the new mechanism(s) so that it can be tested and time given to the developers of all those other applications, services etc..

Applications do not have hardcoded interface names, configuration does and existing configuration means existing installation. to adapt to the new

...

change(s). And then finally switching to the new method as the default. IMHO this transition is being done too rapidly, especially considering the significance of its impact, and not enough time being given to work out the kinks that are likely to occur...

It does not work the way you expect. it is either the new method or the old one in one step. old method: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules New method : NO action required. If you think it is going too fast, you need an "enterprise" distribution or a walking-dead BSD. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Christofer C. Bell

21:07

On Sun, Mar 24, 2013 at 2:10 PM, Cristian Rodríguez wrote:

...

El 24/03/13 14:53, Marc Chamberlin escribió:

...
I suspect there are a lot of services,

...
applications and tools which are very dependent on the device interface name and any sort of a change is very likely to break many of them.

Yes, and that's why the rules must apply only to new installations.

Case

...
in point is this removal of the persistence mechanism for giving/maintaining device names to NICs. In openSuSE 12.3, it's sudden disappearance broke YaST and my ability to use it to set up a gateway system.

Well, it was removed from udev upstream, because it did not work.

...
Such changes should be more orderly, done gradually over a couple of releases, defaulting at first to the continued usage of the old (even if buggy) method(s).

Such change will run in 13.1 , not "between a couple of releases".. you are asking for an approach that will pose a burden on mainteniance and will in practice make things worst, not better.

...
Even better is to pass along with this warning, information on how to move to the new mechanism(s) so that it can be tested and time given to the developers of all those other applications, services etc..

Applications do not have hardcoded interface names, configuration does and existing configuration means existing installation.

to adapt to the new

...
change(s). And then finally switching to the new method as the default. IMHO this transition is being done too rapidly, especially considering the significance of its impact, and not enough time being given to work out the kinks that are likely to occur...

It does not work the way you expect. it is either the new method or the old one in one step.

old method:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

New method : NO action required.

If you think it is going too fast, you need an "enterprise" distribution or a walking-dead BSD.

Honestly, I felt Christian was in the wrong here on how things are moving forward. Up until this last sentence. This is really the clincher, isn't it? If one needs extremely conservative development, then an enterprise distribution is what's most appropriate. I do feel there is a balance, though, between "too fast" (some could argue Fedora fits that bill) and too conservative (I don't think anyone need point anywhere other than Debian for this). This is something that attracts me to openSUSE, to be honest. I feel openSUSE strikes this balance in a way I'm comfortable with. That said, I can empathize with someone (like Marc) who feels openSUSE may be moving a little too fast into that bold new world. -- Chris -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

25 Mar 25 Mar

06:48

Cristian Rodríguez wrote:

...

On 03/24/2013 09:03 AM, Per Jessen wrote:

...
Per Jessen wrote:

...
...
...
However bugs about interface naming should also go to /dev/null in the "disabled" case. :P

This is the kind of attitude that makes people go look for another distro, IMHO.

Sorry, I overlooked your smiley ... need glasses.

Im actually serious, if

- a solution is provided but requires you to let udev rename interfaces. - then bugs about the old "unpredictable interface names " should be marked as WONTFIX.

- People not liking the solution is not the fault of the solution really.

Agree with all of that - the important thing is not forcing new names on people without providing an easy work-around such as renaming or aliases. -- Per Jessen, Zürich (0.3°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

23 Mar 23 Mar

16:41

On 03/23/2013 08:25 AM, Anton Aylward wrote:

...

Cristian Rodríguez said the following on 03/22/2013 10:01 PM:

...
El 20/03/13 16:32, Marc Chamberlin escribió:

...
...
Thanks Robert for your reply, but no joy!

This issue is known and there will be a permanent fix in the next openSUSE release. however, interfaces will change their usual known names.

ARGH!

You mean 13.1 ?

Yes.

...

It's things like this that drive people to Fedora, or *shock* *horror* Ubuntu!

Well, that people you mention are completely stupid. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward

24 Mar 24 Mar

13:41

Cristian Rodríguez said the following on 03/23/2013 12:41 PM:

...

On 03/23/2013 08:25 AM, Anton Aylward wrote:

...
It's things like this that drive people to Fedora, or *shock* *horror* Ubuntu!

Well, that people you mention are completely stupid.

They can't be completely stupid if they are giving up Windows for Linux. -- The master worries about the work, and the apprentice worries about the tools. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

4048

Age (days ago)

4056

Last active (days ago)

List overview

Download

26 comments

8 participants

participants (8)

Andrey Borzenkov
Anton Aylward
Christofer C. Bell
Cristian Rodríguez
Istvan Gabor
Marc Chamberlin
Per Jessen
Robert Schweikert