Network installation from CD

[Dag Wieers]

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]

On Fri, 26 Sep 2008, Dag Wieers wrote:
> 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.
>
> 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.

I forgot to mention this is on RHEL4.6.

[Glenn Bailey]

would pci=bfsort help you out in this situation? it 'should' order
the devices based on PCI id and port #. I'm currently testing it out
in our lab but have only tried it on a HP 585 G2 and it seems to work
perfect on it.
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of
> Dag Wieers
> Sent: Friday, September 26, 2008 9:01 AM
> To: Discussion of Development and Customization of the Red
> Hat Linux Installer
> Subject: Re: Network installation from CD
>
> On Fri, 26 Sep 2008, Dag Wieers wrote:
> > 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.
> > 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.
>
> I forgot to mention this is on RHEL4.6.
>
> --
> --   dag wieers,  [e-mail],  http://dag.wieers.com/   --
> [Any errors in spelling, tact or fact are transmission errors]
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list