-----Original Message-----
From: centos-bounces@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On Behalf
Of Dag Wieers
Sent: Sunday, September 28, 2008 4:59 PM
To: centos@xxxxxxxxxx
Subject: Network installation from CD
Hi,
In a corporate environment we are not allowed to use DHCP/PXE for doing
network installations. This means we have to look for other solutions. Our
solution is to use an ISO image (mounted via a KVM solution) to kick off the
network installation.
A big problem currently is that the order of the network interfaces is
arbitrary (depends on the order of the drivers loaded) and is not influence
by the order of the PCI slots. So in our case we have a bunch of e1000, bnx2
and
tg3 in systems we have to install.
The first onboard interface (usually tg3 or bnx2) almost never is eth0, but
instead can be eth2, eth3 or higher. (Depending on the number of "other"
NICs) This is problematic because Anaconda never gives a very good analysis
of why the download of the kickstart fails. Very unpleasant if you want
system deployements done by Service Operations.
So our solution was to provide ksdevice=MAC-ADDRESS , which works fine in
the first phase for downloading the kickstart file, but then the kickstart
file again has a network-directive with a --device= parameter to configure
the network again in the second phase.
Here is where the trouble starts.
The --device= cannot handle MAC addresses, in other words if we ommit the
--device= parameter we get a list of interfaces, which we do not want
because the list does not indicate which one is the right interface.
Using ksdevice=bootif and providing BOOTIF=MAC-ADDRESS on the
commandline does not help either because the second phase always wants to
reconfigure the network.
In fact we don't want the second phase to reconfigure the network, we want
it to keep the working network configuration from the first phase which
worked fine for downloading the kickstart file.
So here's my question:
Is there a way to have the second phase network configuration NOT take
place, or have it use the interface that was correctly downloading the
kickstart file ?
I could not find it anywhere and none of my tests seem to indicate that this
is at all possible.
This is on RHEL/CentOS 4.6.
---------------------------------------------------------------
JohnStanley Writes:
I thought this issue was fixed in the 2.6.55 release kernel. Also Some where
I came across where there is an option to KS.cfg to use the first available
network connection there is and that was supposed to solve the delima. Maybe
not solved in the 4 release. I had this problem with Dell Servers.
Option is to use a local floppy/cdrom/whatnot and specify "network
--bootproto=dhcp --device=eth0" which you probally don't want.
JohnStanley
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
