[opensuse] Persistent mac <-> ethX in oS 12.3

newer
Re: [opensuse] Absolute path is...

older
[opensuse] firefox vs seamonkey...

Roger Oberholtzer

3 Oct 2013 3 Oct '13

15:52

I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different. I thought I could add something like this as a udev rule: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:36:9f:00:5f:69", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:36:9f:00:5f:6a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:36:9f:00:5f:68", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:36:9f:00:5f:69", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:36:9f:00:5f:6a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:36:9f:00:5f:6b", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4" But this seems not to be used. I wonder why. YaST seems to have a different idea of which MAC addresses go with which ethX. I would have thought that if the udev rule made the ethX values as I want, then YaST need not get involved with MAC addresses. As it is, the network is unusable. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

Per Jessen

3 Oct 3 Oct

16:26

Roger Oberholtzer wrote:

...

I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.

I thought I could add something like this as a udev rule:

In 12.3, 70-persistent-net.rules should be automatically set up for you. -- Per Jessen, Zürich (14.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

4 Oct 4 Oct

11:08

On Thursday, October 03, 2013 06:26:21 PM Per Jessen wrote:

...

Roger Oberholtzer wrote:

...
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.

...
I thought I could add something like this as a udev rule: In 12.3, 70-persistent-net.rules should be automatically set up for you.

It is. But the problem is that the file is set up however the BIOS reported the devices when the system was installed (it seems). If that changes in a later boot, it seems that the rules no longer work. As I suggested, perhaps that is because of possible conflicts with the original names. I surely cannot rename an interface in the rules file to be the same as an existing one. And when the order of when each rule changes (the BIOS presents the list in a different order), this may happen. If I use a new naming scheme so that a conflict does not arrise, the udev rules work every time. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

12:06

Roger Oberholtzer wrote:

...

On Thursday, October 03, 2013 06:26:21 PM Per Jessen wrote:

...
Roger Oberholtzer wrote:

...
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.

...
I thought I could add something like this as a udev rule: In 12.3, 70-persistent-net.rules should be automatically set up for you.

It is. But the problem is that the file is set up however the BIOS reported the devices when the system was installed (it seems). If that changes in a later boot, it seems that the rules no longer work.

Hmm, I can't quite follow you - _what_ exactly changes in a later boot? The MAC addresses?

...

As I suggested, perhaps that is because of possible conflicts with the original names. I surely cannot rename an interface in the rules file to be the same as an existing one.

Correct. Because of the possiblity of using the same names (eth0-1-2-3-4-5...) but on different mac-addresses, usually devices are first renamed to <somethingelse>, then renamed to the names specified.

...

And when the order of when each rule changes (the BIOS presents the list in a different order), this may happen.

No, the order isn't (shouldn't be) relevant for the rules. They simply take a MAC-address and rename the interface when it matches. Of course, if your driver has named an interface 'eth0' and you try to use that too, it won't work. Do you have rename rules for all 6 MACs ? -- Per Jessen, Zürich (15.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

13:17

On Friday, October 04, 2013 02:06:22 PM Per Jessen wrote:

...

Roger Oberholtzer wrote:

...
On Thursday, October 03, 2013 06:26:21 PM Per Jessen wrote:

...
Roger Oberholtzer wrote:

...
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.

...
I thought I could add something like this as a udev rule: In 12.3, 70-persistent-net.rules should be automatically set up for you.

It is. But the problem is that the file is set up however the BIOS reported the devices when the system was installed (it seems). If that changes in a later boot, it seems that the rules no longer work.

Hmm, I can't quite follow you - _what_ exactly changes in a later boot? The MAC addresses?

No. It is the same MAC address for each NIC. But the order the kernel discovers the NICS seems to change in some boots. Even if there is no change to the hardware at all. When this happens, whatever is eth0 may change. I would have thought that the udev rule would have sorted this. And it does if the names are guaranteed not to conflict with the traditional ethNUMBER names.

...

...
As I suggested, perhaps that is because of possible conflicts with the original names. I surely cannot rename an interface in the rules file to be the same as an existing one.

Correct. Because of the possiblity of using the same names (eth0-1-2-3-4-5...) but on different mac-addresses, usually devices are first renamed to <somethingelse>, then renamed to the names specified.

The naming to <somethingelse> must first happen for all devices. Then they can be named as specified. But the udev rule is done as each devices is added. So you must get to the final name directly. Unless I missed some neat trick.

...

...
And when the order of when each rule changes (the BIOS presents the list in a different order), this may happen.

No, the order isn't (shouldn't be) relevant for the rules. They simply take a MAC-address and rename the interface when it matches. Of course, if your driver has named an interface 'eth0' and you try to use that too, it won't work. Do you have rename rules for all 6 MACs ?

I would have thought the same. In fact, that is how I started. But it simply did not work. I have rules for all existing NICs. I think part of the problem may be that one card has 4 NIC. When that card is found, I bet all 4 NIC get a kernel name. Then the udev add rules get called for each, one at a time. If the first udev rule wants to name a NIC to one of the 3 addresses for the other NIC on the card, it may fail. Just a guess. There is no message in /var/log/messages. It just does not work. So I have names like ethA, ethB, etc. But I do not want that! -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

13:48

Roger Oberholtzer wrote:

...

On Friday, October 04, 2013 02:06:22 PM Per Jessen wrote:

...
Roger Oberholtzer wrote:

...
On Thursday, October 03, 2013 06:26:21 PM Per Jessen wrote:

...
Roger Oberholtzer wrote:

...
I have a rather new SuperMicro MB that has two on-board NIC, as well as a card with 4 Intel NIC ports. The problem is that it seems that the BIOS does not report these in the same order (I am guessing) so that the same NIC gets the same ethX across reboots. 90% of the time they are the same. But the rest of the times they are different.

...
I thought I could add something like this as a udev rule: In 12.3, 70-persistent-net.rules should be automatically set up for you.

It is. But the problem is that the file is set up however the BIOS reported the devices when the system was installed (it seems). If that changes in a later boot, it seems that the rules no longer work.

Hmm, I can't quite follow you - _what_ exactly changes in a later boot? The MAC addresses?

No. It is the same MAC address for each NIC. But the order the kernel discovers the NICS seems to change in some boots.

Yes, that is possible, for instance if the modules are loaded in a different order. (presuming the on-board and your card use different drivers).

...

I have rules for all existing NICs. I think part of the problem may be that one card has 4 NIC. When that card is found, I bet all 4 NIC get a kernel name.

Yes, ethX, X incremented once per interface port. I have a couple of boxes with 4-port NICs too, I have no such problems. Okay, none of them is running 12.3, they're older systems.

...

Then the udev add rules get called for each, one at a time. If the first udev rule wants to name a NIC to one of the 3 addresses for the other NIC on the card, it may fail. Just a guess.

You should be able to see what happens in the dmesg output.

...

There is no message in /var/log/messages. It just does not work. So I have names like ethA, ethB, etc. But I do not want that!

You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction. -- Per Jessen, Zürich (18.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

15:11

On Friday, October 04, 2013 03:48:15 PM Per Jessen wrote:

...

You should be able to see what happens in the dmesg output.

That only lists the initial kernel assignment of an ethX name befote the udev add rule is called. The names stay as listed here, despite the udev rules. Unless I use a different nameing scheme i.e., ethA). As to what caused this: who knows. We have the combination of a new SuperMicro MB and oS 12.3. I still suspect that the SuperMicro is the difference. I have the feeling that the older ones always reported the MB NICs first, followed by those on cards. Now it liike like you can get the first MB NIC, then the card, then the last MB NIC. Or any other order.

...

...
There is no message in /var/log/messages. It just does not work. So I have names like ethA, ethB, etc. But I do not want that!

You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.

I suspect you are right. I do look forward to this feature. I hope it will be working. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

16:27

Roger Oberholtzer wrote:

...

On Friday, October 04, 2013 03:48:15 PM Per Jessen wrote:

...
You should be able to see what happens in the dmesg output.

That only lists the initial kernel assignment of an ethX name befote the udev add rule is called. The names stay as listed here, despite the udev rules. Unless I use a different nameing scheme i.e., ethA).

As to what caused this: who knows. We have the combination of a new SuperMicro MB and oS 12.3. I still suspect that the SuperMicro is the difference. I have the feeling that the older ones always reported the MB NICs first, followed by those on cards. Now it liike like you can get the first MB NIC, then the card, then the last MB NIC. Or any other order.

I think it's more likely to do with the order of the modules being loaded. The build-in NICs are likely on one of the first PCI-busses, the 4-port card on one of the later. I'm not sure if modules are loaded in order of PCI-location, but there's no inter-dependence so whoever's first ...

...

...
...
There is no message in /var/log/messages. It just does not work. So I have names like ethA, ethB, etc. But I do not want that!

You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.

I suspect you are right. I do look forward to this feature. I hope it will be working.

It looks like it is - I've hit one or two bugs, but my situation is a little exotic. Anyway, I intend to stick to ethN :-) -- Per Jessen, Zürich (18.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov

15:27

В Fri, 04 Oct 2013 15:48:15 +0200 Per Jessen пишет:

...

You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.

Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

16:27

Andrey Borzenkov wrote:

...

В Fri, 04 Oct 2013 15:48:15 +0200 Per Jessen пишет:

...
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.

Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is.

Agree. -- Per Jessen, Zürich (18.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

7 Oct 7 Oct

06:55

On Friday, October 04, 2013 06:27:44 PM Per Jessen wrote:

...

Andrey Borzenkov wrote:

...
В Fri, 04 Oct 2013 15:48:15 +0200

Per Jessen пишет:

...
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.

Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is.

Agree.

OOC, does the udev rule happen when the NIC is found, or when a cable is plugged to it? Another odd problem: It used to be that when you plugged in or took out the network cable, you got a message in /var/log/messages that the activity had occurred. I no longer see this. Also, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'. This is on a couple machines. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

07:15

Roger Oberholtzer wrote:

...

On Friday, October 04, 2013 06:27:44 PM Per Jessen wrote:

...
Andrey Borzenkov wrote:

...
В Fri, 04 Oct 2013 15:48:15 +0200

Per Jessen пишет:

...
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.

Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is.

Agree.

OOC, does the udev rule happen when the NIC is found, or when a cable is plugged to it?

I believe the renaming happens as early as possible, ie. when the NIC device is recognized during boot-up.

...

Another odd problem:

It used to be that when you plugged in or took out the network cable, you got a message in /var/log/messages that the activity had occurred.

I've never seen any such messages, maybe they are from the Network Manager? Or maybe you need NICs configured as "onplug" (can't remember the correct term).

...

I no longer see this. Also, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'. This is on a couple machines.

The NIC LEDs and the interface config status are independent, afaik. Usually one LED indicates connection (sometimes also speed), the other indicates activity on the network. -- Per Jessen, Zürich (12.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

09:13

On Monday, October 07, 2013 09:15:19 AM Per Jessen wrote:

...

Roger Oberholtzer wrote:

...
On Friday, October 04, 2013 06:27:44 PM Per Jessen wrote:

...
Andrey Borzenkov wrote:

...
В Fri, 04 Oct 2013 15:48:15 +0200

Per Jessen пишет:

...
You could try opening a bugreport, but as NIC enumeration is about to change significantly, you might not get much traction.

Well, it is still supposed to work in 12.3, if it does not - it is a bug. But so far description was far too vague to even guess what the problem is.

Agree.

OOC, does the udev rule happen when the NIC is found, or when a cable is plugged to it?

I believe the renaming happens as early as possible, ie. when the NIC device is recognized during boot-up.

...
Another odd problem:

It used to be that when you plugged in or took out the network cable, you got a message in /var/log/messages that the activity had occurred.

I've never seen any such messages, maybe they are from the Network Manager? Or maybe you need NICs configured as "onplug" (can't remember the correct term).

I will check that. In our system, the connections are fine at boot. We have not changed the settings. On a different 12.3 system, with similar persistent cabled connections, I see this when I unplug/plug a cable: kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up But not on the system I am trying to sort out.

...

...
I no longer see this. Also, even though the LEDs in the NIC light as expected, the link is not list as up in 'ip addr'. This is on a couple machines.

The NIC LEDs and the interface config status are independent, afaik. Usually one LED indicates connection (sometimes also speed), the other indicates activity on the network.

Indeed. I just meant that a link is sensed by the NIC (the cable has a connection at the other end). -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

09:48

Roger Oberholtzer wrote:

...

On a different 12.3 system, with similar persistent cabled connections, I see this when I unplug/plug a cable:

kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up

I don't remember seeing those, are they logged to /var/log/messages ? -- Per Jessen, Zürich (14.3°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

10:12

On Monday, October 07, 2013 11:48:34 AM Per Jessen wrote:

...

Roger Oberholtzer wrote:

...
On a different 12.3 system, with similar persistent cabled

connections, I see this when I unplug/plug a cable: kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up

I don't remember seeing those, are they logged to /var/log/messages ?

Yes. I usually have used them to see what NIC is what. Very handy. When they worked... I am also curious why the link status (e.g., UP) no longer gets set when the cable is plugged in. In both systems, the sysconfig file for the interface is: BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='10.2.10.41/24' MTU='' NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' IPADDR_0='10.1.5.1/24' LABEL_0='ANTS' With only IPADDR, NAME and IPADDR being different. Both systems use the traditional way to bring up the interfaces. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

14:04

Roger Oberholtzer wrote:

...

On Monday, October 07, 2013 11:48:34 AM Per Jessen wrote:

...
Roger Oberholtzer wrote:

...
On a different 12.3 system, with similar persistent cabled

connections, I see this when I unplug/plug a cable: kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up

I don't remember seeing those, are they logged to /var/log/messages ?

Yes. I usually have used them to see what NIC is what. Very handy. When they worked...

I am also curious why the link status (e.g., UP) no longer gets set when the cable is plugged in.

I think your startmode needs to be "ifplugd", but check in YaST. -- Per Jessen, Zürich (14.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer

14:16

On Monday, October 07, 2013 04:04:08 PM Per Jessen wrote:

...

Roger Oberholtzer wrote:

...
On Monday, October 07, 2013 11:48:34 AM Per Jessen wrote:

...
Roger Oberholtzer wrote:

...
On a different 12.3 system, with similar persistent cabled

connections, I see this when I unplug/plug a cable: kernel: [340741.476759] r8169 0000:0a:00.0 eth0: link down kernel: [340743.984668] r8169 0000:0a:00.0 eth0: link up

I don't remember seeing those, are they logged to /var/log/messages ?

Yes. I usually have used them to see what NIC is what. Very handy. When they worked...

I am also curious why the link status (e.g., UP) no longer gets set when the cable is plugged in.

I think your startmode needs to be "ifplugd", but check in YaST.

In YaST, "Traditionla method with ifup" is selected. This is what I always have for these types of systems. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott

14:42

Roger Oberholtzer wrote:

...

In YaST, "Traditionla method with ifup" is selected. This is what I always have for these types of systems.

Even there, you have options. For example, on my main system, where I use static configuration, I have set Device Activation to At Boot Time. If I used DHCP, I would go with On Cable Connection, as unplugging and reconnecting the cable is an easy way to force DHCP to run again. On my notebook computer I use the network manager to handle the connection, as I could be using either Ethernet or WiFi. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen

16:39

James Knott wrote:

...

Roger Oberholtzer wrote:

...
In YaST, "Traditionla method with ifup" is selected. This is what I always have for these types of systems.

Me too, but "ifplugd" is an option per interface.

...

Even there, you have options. For example, on my main system, where I use static configuration, I have set Device Activation to At Boot Time. If I used DHCP, I would go with On Cable Connection,

That's the one I'm talking about. I'm pretty certain that becomes startmode=ifplugd. -- Per Jessen, Zürich (13.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org