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
that 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.
Here is where the trouble starts.
The --device= cannot handle MAC addresses, in other words we either
ommit the parameter (causing us to get a list of interfaces, which we do not
want because the list does not tell 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 retain the working network configuration that 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.
--
-- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
