On Thu, Dec 30, 2004 at 08:34:29PM -0500, Alex Angerhofer wrote:
On Thu, 30 Dec 2004, Alex Angerhofer wrote:
On Thu, 30 Dec 2004, Patrick Shanahan wrote:
* Alex Angerhofer
[12-30-04 17:43]: I guess it was too early to report success here. After a reboot the same reversal of eth devices happened as before. I guess, the correct solution should not be to use the deprecated old ethx names but rather go with the MAC-related names. But that would require SuSE to fix their 9.2 version of the dhcpd packages (at least on x86_64, don't know about i386).
I suggest you read or re-read the message thread that was proposed previous. It had a *solution* which would survive a reboot and an explanation. And it did not indicate the necessity for a bug-report.
Dear Patrick,
thanks for the exhortation. I scanned the thread again. I had tried both main solutions that were recommended, i.e., placing extra udev rules and using the PERSISTENT_NAMES field in the /etc/sysconfig/network/ifcfg-eth-id-MAC files, but neither one worked for me. I am still following up on some extra googling I have been doing. However, even if there is a solution that forces the devices to come up with persistent names, it is still a bug that dhcpd doesn't recognize device names that are more than 15 characters long. Furthermore, this had been fixed in SuSE 9.1 with a YOU update patch, which didn't make it into the 9.2 updates. Thus I filed a bug report and for the time being am switching the ethx names by hand.
Best regards, Alex.
I finally seem to have it working now. It took another look at the SuSE knowledgebase here: http://support.novell.com/cgi-bin/search/searchtid.cgi?/en/2004/05/91_coldho... If you scroll down to the heading "Network Devices and Their Interface Names" you will find a reference to the race condition that exists when the nics are called up. The recommended procedure is to set HOTPLUG_PCI_QUEUE_NIC_EVENTS=no *and* at the same time "set dedicated interface names in the interface configuration files." In fact when you go to the sysconfig editor ---> Hardware ---> Hotplug --> HOTPLUG_PCI_QUEUE_NIC_EVENTS the text advises you that you don't need this set if you use PERSISTENT_NAMES for your interfaces.
You are misunderstanding this section. The default for HOTPLUG_PCI_QUEUE_NIC_EVENTS is _yes_, the events are queued and the race condition that might change the order does not happen. Even if you use configuration names ifcfg-eth* you will not have problems unless you move cards in the machine, update kernel or hotplug or update something else which might change the initialization order for this reason or another. The fundamental thing to understand here is that the interface names eth0, eth1 and so on _can_ be subject to change, but it does _not_ matter: _Only_ if a service like dhcpd is started with 'dhcpd eth0' you can get into trouble, and that's why dhcpd is started like this since 9.1: dhcpd $(getcfg-interface eth-id-<mac>) The configuration name which is used for the lookup of the actual, current interface name is the one you used as filename for the ifcfg- file in /etc/sysconfig/network. These configuration names are put into DHCPD_INTERFACE in /etc/sysconfig/dhcpd. The YOU update for 9.1 at the time actually introduced the getcfg-interface lookup which had been forgotten at that place. You _can_ use "easier" names like internal0/internal1/external, or good/bad if you want, by assigning such names via PERSISTENT_NAMES. (You cannot use eth* as persistent names, that is not possible.) Thus, if you stick to the hotplug defaults (so the initialization order fixed) and use the recommended configuration names (eth-id-something, so the configuration is coupled to a piece of hardware), I can assure you that the interface names will not change at will. (Unless there is some weird bug preventing it to work but as far as I can tell it works fine.) Still, you should replace all references to eth0, eth1 and so on in your configuration files by $(getcfg-interface eth-id-<mac>) calls. This is done in init scripts shipping with 9.1 onwards, so they work directly with the configuration names instead of interface names, as explained above with the /etc/sysconfig/dhcpd example. And I can _assure_ you that the fix is not only in 9.1, but also in 9.2. If you still see the problem please let me know. At first, please check the DHCPD_INTERFACE in /etc/sysconfig/dhcpd and make sure it is in sync with your ifcfg-* files.
Still, the dhcpd behavior is a bug and ought to be fixed.
Is your interface name longer than 15 characters? No, is it?
Cheers, Alex.
Peter