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