Here's a hacky way to do this:

Since you know the MAC address, you can cheat and setup the network later (I
think this will work).

Leave ksdevice=<MAC address>

Leave the network stuff blank, we'll fix it in post (alternatively you can
set it up and nuke it in post)
Network --disable

In %POST do something like this (the if is not formatted correctly, you can
figure it out though)

TEST1=`cat /etc/sysconfig/network-scripts/ifcfg-eth0 |grep <MAC address>`
If TEST1 = '' then
IFWANTED = 'eth0'
Else
IFWANTED = 'eth1'

Then you echo the ifcfg file to the correct spot

Echo 'DEVICE="$IFWANTED"' > /etc/sysconfig/network-scripts/if-cfg$IFWANTED
Echo 'ONBOOT=yes' >>/etc/sysconfig/network-scripts/if-cfg$IFWANTED
.....

Something like that may work for you, there's a lot of power in %POST

-Jordan


 

-----Original Message-----
From: [log in to unmask]
[mailto:[log in to unmask]] On Behalf Of Floris
Bos
Sent: Monday, February 07, 2011 12:48 PM
To: [log in to unmask]
Subject: Re: SL6 ksdevice issue

Hi,

On Monday, February 07, 2011 06:29:29 pm Stephan Wiesand wrote:
> On Feb 6, 2011, at 00:11 , Floris Bos wrote:
> > ==
> > ksdevice=11:22:33:44:55:66
> > ==
> > 
> > And specify a static IP-address (the same as assigned by DHCP), 
> > without explicity naming an Ethernet device in the kickstart file, e.g.:
> > 
> > ==
> > network --bootproto=static --ip=10.0.0.10 --netmask=255.255.255.0 --
> > gateway=10.0.0.1 --nameserver=127.0.0.1 --hostname=hostname ==
> > 
> > Under Centos 5.5 and Fedora this works correctly, and causes the 
> > network device specified by ksdevice to be used.
> > 
> > However it does not seems to work with SL6 beta.
> 
> this is probably a "6 vs. 5" issue rather than am "SL vs. CentOS/Fedora"
> one.

Quite possible.
But I don't have a license for the upstream vendor software, so cannot test
if this is the case.


> Unless you have a special reason to have the interface named eth1, it may
> be better to have it recognized as eth0 in the first place. We're now
> generally using "ksdevice=link pci=bfsort" when kickstarting, which makes
> the "primary" NIC (as seen by the BIOS/vendor) eth0 during installation on
> all our servers which would otherwise recognize it as eth1, avoiding all
> these problems.

Well, that still requires the cable to be in the first port, which might be 
best practice, but is not always reality.

We develop software for small- to medium size hosting providers, for 
provisioning and managing dedicated servers.
Those usually do not have personell on-site, and it might be a long drive to

the data center.
So we rather find a way to make the software just work, regardless which
port 
is used.


-- 
Yours sincerely,

Floris Bos