Has anyone else noticed that the x86_64 kernel enumerates the PCI bus differently than the i686 kernel? We have an Opteron platform where the first ethernet port shows up as "eth0" with the i686 kernel and "eth1" with the x86_64 kernel. Red Hat claims this is because the x86_64 kernel uses ACPI and the i686 kernel does not. Since we want to be able to install these Opteron systems with 32-bit or 64-bit Linux AND have the Ethernet interface be eth0 at all times, any clues on how we'd accomplish this?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133150
/Brian/
Just an idea - perhaps you can use the mac address to order interfaces. I just checked on a couple of Dell servers, and eth1's mac address is consistently eth0 - 1.
Grisha
On Wed, 29 Sep 2004, Brian Long wrote:
Has anyone else noticed that the x86_64 kernel enumerates the PCI bus differently than the i686 kernel? We have an Opteron platform where the first ethernet port shows up as "eth0" with the i686 kernel and "eth1" with the x86_64 kernel. Red Hat claims this is because the x86_64 kernel uses ACPI and the i686 kernel does not. Since we want to be able to install these Opteron systems with 32-bit or 64-bit Linux AND have the Ethernet interface be eth0 at all times, any clues on how we'd accomplish this?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133150
/Brian/
Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
That's a fine work-around for already installed systems, but what about during kickstart?
Same OS, Same hardware, different arch shouldn't mean eth0 and eth1 get swapped. Either i686 and x86_64 should both use ACPI for enumeration or neither should; this would maintain consistency.
/Brian/
On Wed, 2004-09-29 at 11:28, Gregory (Grisha) Trubetskoy wrote:
Just an idea - perhaps you can use the mac address to order interfaces. I just checked on a couple of Dell servers, and eth1's mac address is consistently eth0 - 1.
Grisha
On Wed, 29 Sep 2004, Brian Long wrote:
Has anyone else noticed that the x86_64 kernel enumerates the PCI bus differently than the i686 kernel? We have an Opteron platform where the first ethernet port shows up as "eth0" with the i686 kernel and "eth1" with the x86_64 kernel. Red Hat claims this is because the x86_64 kernel uses ACPI and the i686 kernel does not. Since we want to be able to install these Opteron systems with 32-bit or 64-bit Linux AND have the Ethernet interface be eth0 at all times, any clues on how we'd accomplish this?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133150
/Brian/
Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Wed, Sep 29, 2004 at 11:40:12AM -0400, Brian Long wrote:
That's a fine work-around for already installed systems, but what about during kickstart?
During kickstart, I use ksdevice=link as a boot paramater, so kickstart uses the (first) NIC that's plugged in to as switch.
After kickstart, the way to keep ethX->device mapping consistent is to use nameif and /etc/mactab.
Same OS, Same hardware, different arch shouldn't mean eth0 and eth1 get swapped. Either i686 and x86_64 should both use ACPI for enumeration or neither should; this would maintain consistency.
RHEL 3 i686 doesn't use ACPI for enumeration. It wasn't stable enough when RHEL3 was released. For x86_64, ACPI was specified by the architecture as being the *only* way to get that information. Thus RHEL3 x86_64 *had* to use ACPI. But that's no reason to go and change the way RHEL3 works for existing i686 users. That's one of the tenants of the RHEL product line - if it ain't broke, don't fix it, but you can change it in the next major release (not an Update).
RHEL4, now in public beta, should be consistent in its use of ACPI for both architectures.
Thanks, Matt
anaconda-devel@lists.stg.fedoraproject.org
-
Brian Long -
Gregory (Grisha) Trubetskoy -
Matt Domsch