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.
Dag Wieers wrote:
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.
Dag,
I ASSuME that different interfaces are plugged into different switch ports on a switch supporting VLANs? Perhaps the same switch for all ports.
Can you set up those ports, so that for install, they are all on the same VLAN? So it would not matter which interface is used for the install, the IP address you assign it will work on it?
My home lab has a number of HP ProCurves, and I will get into the management interface, and set which vlan a port is on if I need to do some installs.
On Sun, 28 Sep 2008, Robert Moskowitz wrote:
Dag Wieers wrote:
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.
I ASSuME that different interfaces are plugged into different switch ports on a switch supporting VLANs? Perhaps the same switch for all ports.
Can you set up those ports, so that for install, they are all on the same VLAN? So it would not matter which interface is used for the install, the IP address you assign it will work on it?
Robert,
The problem here is that multiple teams are involved and every additional step does not only make the whole installation harder, it makes it more error-prone.
The 2 datacenters are 400km away, the teams speak another language.
And frankly, if we specify the MAC address and we can have a proper network going to download the kickstart file. We should be able to do the same for the second phase (downloading the media/packages).
Adding a step where room-management is going to repatch the system is highly undesirable, because it should be avoidable.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Dag Wieers Sent: Sunday, September 28, 2008 4:59 PM To: centos@centos.org Subject: [CentOS] 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@centos.org http://lists.centos.org/mailman/listinfo/centos
John wrote on Mon, 29 Sep 2008 02:00:15 -0400:
JohnStanley Writes:
It would really help to find something useful in your postings if you were to quote in a standard way. AFAIK, Outlook 11 *can* do this.
Kai
On Sun, Sep 28, 2008 at 16:59, Dag Wieers dag@wieers.com wrote:
Is there a way to have the second phase network configuration NOT take place,
Not that I know of.
or have it use the interface that was correctly downloading the kickstart file ?
Yes!
I do something similar here. I use a script to generate the "network" line, because I want to choose my IPs and netmasks during installation and I don't want to hardcode them in the ks.cfg file.
Here is what I do:
I create a %pre section to ks.cfg, this will be a script (in my case a Python script) that will ask the user for any needed information. Then it will look up the boot-up interface by looking at /proc/sys/net/ipv4/conf and choosing the first entry that starts with "eth", then it will generate a "network" line and save it to /tmp/netconfig.
Then, before on the ks.cfg file, where the network configuration is expected, I use a %include /tmp/netconfig
For me, it works like a charm! Let us know if you try it and it works for you.
HTH, Filipe
-
Dag Wieers -
Dag Wieers -
Filipe Brandenburger -
John -
Kai Schaetzl -
Robert Moskowitz