Since you're putting an initrd on the server, why not edit your initrd,
and put your kickstart in it?
http://www.alexonlinux.com/opening-and-modifying-the-initrd
http://smshaker.wordpress.com/2009/03/23/modifying-initrdimg/
You would then reference your kickstart file like this: ks=file:/ks.cfg
In a %pre section, use bash & the ip tools to detect your link status
and dev names, or by cat'ing the appropriate file in /sys/class/net/.
Another way to test your link is to try mounting your nfs share, and if
it does not succeed, you know that the network did not come up correctly.
At that point, you should be able to correct the network setup using
some invocation of: ip link set, etc . Of course, you could just run the
ip commands w/o bothering to test your connectivity first. Just assume
that the network didn't come up correctly and specify your settings.
Specify your nfs install source inside your kickstart file instead of on
the grub kernel line.
In a %post section, write your network config into the proper
/etc/sysconfig/network-scripts/ifcfg-eth* files.
Make sure to set the cmdline option on your kernel boot line, that
should prevent anaconda from asking for any information.
This is all probably way more effort than you want to put in, but I
think that it should solve your issues assuming it works. Unfortunately,
I don't have time to fireup a VM and test this right now.
--W
On 3/5/2012 9:01 AM, Stephen Berg (Contractor) wrote:
> On 03/05/2012 07:37 AM, Stephen Berg (Contractor) wrote:
>> I'm testing a way to install/upgrade some remote systems. What I'm
>> doing is hand 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.
>>
>> When I boot to this kernel/image combination I use the following boot
>> parameters to get a psuedo netboot/pxeboot installation started:
>>
>> 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.
>> [...]
> 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.
>
>
|