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. Still, the dhcpd behavior is a bug and ought to be fixed. Cheers, Alex.