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.
