Getting Anaconda to pickup the desired NIC is always a bit of a bear for 
me when running an install/upgrade from a local drive.

>  On 03/05/2012 07:37 AM, Stephen Berg (Contractor) wrote:
[...snip...]
> >jamming a change in /boot/grub/grub.conf to point to /boot/vmlinuz and 
/boot/initrd.img from the /image/pxeboot directory off the install DVD, 
tried both 6.1 and 6.2. Both files have been copied to /boot on the test 
server.

Can you post your grub.conf lines? And maybe what kind of NICs you're 
using? Logs? Why the pxeboot kernel & initrd if you're not using pxe?

I wonder if feeding the kernel BOOTIF and ksdevice=bootif would fool it 
into doing what you want.  BOOTIF holds the hardware type (ARP type 
code) and address in lower case hexadecimal with dash separators 
(http://www.syslinux.org/wiki/index.php/Doc/pxelinux).
One possibility (assuming you know your MAC address ahead of time) would 
be to use something like the following kernel line in grub for your test 
box:
kernel /boot/vmlinuz-pxe-install BOOTIF=01-00-11-1f-a1-24-4b 
ksdevice=bootif ks=nfs:10.8.5.11:/sl_export/kickstarts/sl6/sl6.2.ks 
repo=nfs:10.8.5.11:/sl_export/sl6/6.2/i386/os ip=10.8.5.21 
netmask=255.255.255.0 gateway=10.8.5.1 dns=10.8.5.11 noipv6 nicdelay=10 
b=us nofirewire nokill cmdline sshd


If I were  going to try this via static network config, I would probably 
try something like:
ks=nfs:10.8.5.11:/sl_export/kickstarts/sl6/sl6.2.ks 
repo=nfs:10.8.5.11:/sl_export/sl6/6.2/i386/os ksdevice=00:11:1f:a1:24:4b 
ip=10.8.5.21 netmask=255.255.255.0 gateway=10.8.5.1  dns=10.8.5.11 
noipv6 nicdelay=10 b=us nofirewire nokill cmdline
You might try prepending the 01: for ether to the ksdevice when using 
MAC Address. In the above example, you might try 
ksdevice=01:00:11:1f:a1:24:4b. Anaconda is supposed to prepend the 01 to 
ksdevice for you, but eh, one never knows for sure.

Something like the above should help debug what anaconda is doing and why:
- cmdline should make it print what it's really doing.
- nokill should keep the machine from rebooting, or terminating any 
processes
- nicdelay=10 should give the kernel all the chance in the world of 
getting it right.

Is there any chance of doing a real pxeboot? I.e. with a dhcp server & 
tftp server?

--W of BHE

On 3/5/2012 9:01 AM, Stephen Berg (Contractor) wrote:
>  On 03/05/2012 07:37 AM, Stephen Berg (Contractor) wrote:
[...snip...]
> > ks=nfs:<IPADDRESS>:<PATH to kickstart> ksdevice=link vnc vncpassword=<PW>
> >
> > The problem I'm running into is that the ksdevice parameter seems to 
be getting ignored. I've tried ksdevice=ethX with the appropriate 
network interface name, ksdevice=link and ksdevice=<MACADDR> but the 
system consistently stops at the screen asking me to choose which 
interface to use.
> >
> > I tried a similar method using a Fedora 15 vmlinuz/initrd.img and 
ksdevice=link and it worked as expected. Is there some magic I'm missing 
or is that ksdevice parameter not functioning properly from the install 
DVD's copies of vmlinuz/initrd.img?
>
>  Forgot to mention this system has two NIC's, both enabled but only one 
has an active link. In SL6.x the active link shows up as eth1, during 
the test with Fedora 15 that I mentioned the active link came up as eth0.