CentOS 6 kickstart install fails when attempting to download packages.

[eclay]

hello,

I've run into a problem installing CentOS 6 on systems with the 82574L nic. During the install I see the following. The system attempts to install via eth1, which is actually eth0 (physically), this isn't a big issues since the install should run and complete without issue. The problems start right after the partitions are formatted and before the server attempts to download the packages to install. What I'm seeing before the install stops as the following.

-while the formatting is taking place I see eth1 with a 10.x.x.x address and no eth0. The default route is set to the 10.x.x.x router to allow access to the cobbler/kickstart server.
-At some point after the formats complete both eth0/1 are activated and have IP addresses and teh default route is set to the public router removing the previously set by dhcp default route to the 10.x.x.x network. Install fails and prompts you to retry or reboot.

At this point if I switch over to the second virtual terminal (Alt+F2) I can manually add a route to which allows the server being installed to communicate with the cobbler/kickstart server. I can then choose to retry and the install completes. Once the server finishes the install and reboots the network interfaces are see properly eth0 as eth0 and the same for eth1. I can communicate with the network without issue.

To attempt to fix this I added a static route line to the systems cobbler object. This didn't seem to add the route during the install.

When I perform a CentOS 5.6 install on the same hardware I see this main difference. When the install completes the formatting of the partitions and then attempts to install the packages, the network settings are not changed. I have the same eth# active and the same routes received by dhcp and the public interface remains not bound. In this scenario the install finishes without any issues.

From what I've been able to gather the issue seems to be related to the difference in CentOS 6 that attempt to make the kickstart provided network settings active before attempting to install instead of just using the settings received from dhcp when the install was initiated.

When I attempt to use servers without these network interfaces, that use eth0 as there ksdevice I don't see this issue. Installs complete without issue on both 5.6 and 6.

Anyone have any ideas on how to work around this?

Thanks

[eclay]

Comparing the results on this system that the install fails on and one that works. I see that both working and non working have Intel 82574L nics but the one that fails is using eth1 as the ksdevice and the one that works uses eth0. What seems to happen is when network manager starts up or activates, it wants to apply a default route to eth0 if one isn't already set for eth0. In the case of the failing system, the default route is set initially on eth1 and it gets clobbered since the one it thinks should be on eth0 is used. It uses the default route as defined by the kickstart file.

[atemp]

How do you start your kickstart installation, with a PXE boot?

[eclay]

Yes, the install is initiated via pxe boot. The following is what cobbler creates when enabling a pxe install.

default linux
prompt 0
timeout 1
label linux
kernel /images/CentOS6.0-x86_64-test/vmlinuz
ipappend 2
append initrd=/images/CentOS6.0-x86_64-test/initrd.img ksdevice=bootif lang= kssendmac

[atemp]

[quote]
eclay wrote:
Yes, the install is initiated via pxe boot. The following is what cobbler creates when enabling a pxe install.

default linux
prompt 0
timeout 1
label linux
kernel /images/CentOS6.0-x86_64-test/vmlinuz
ipappend 2
append initrd=/images/CentOS6.0-x86_64-test/initrd.img ksdevice=bootif lang= kssendmac
[/quote]

Okay, ipappend 2 and ksdevice=bootif is exactly what i would suggest. The only thing i do not use is those kssendmac, maybe you want to try it without it?


What about the network line in the kickstart file, are you sure you did not add any devices? Mine looks just like that:

network --bootproto dhcp

Sorry that i have no better ideas.

[eclay]

Our kickstart file sets both eth0 and eth1's ips statically. We only use dhcp for initial pxe installations.

The kssendmac setting does the following. I'm guessing it's required for cobbler.

If you add the option kssendmac, the request also sends HTTP headers to the Web application. Your application can use these headers to identify the computer. This line sends a request with headers to the application http://server.mydomain.com/kickstart.cgi:

linux ks=http://server.mydomain.com/kickstart.cgi kssendmac

http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/sn-automating-installation.htm

[atemp]

[quote]
eclay wrote:
Our kickstart file sets both eth0 and eth1's ips statically. We only use dhcp for initial pxe installations.
[/quote]

What about trying it with DHCP only? If that solves the problem then you can make the static IP config in the %post section of the kickstart file.

[eclay]

If I remove all networking settings along with settings put in the pre_install script and set just eth1 to be configured by dhcp, I can get the install to complete normally. The problem I'm faced with is one of the machine types that we use, CentOS 6.0 switches eth0 and eth1 during install. After the install completes they are seen properly.

Following two entries removed.
## Network configuration
$SNIPPET('network_config')

%pre
$kickstart_start
$SNIPPET('pre_install_network_config')

-Which gets populated with the following by cobbler.
---legion----
x.x.x.x = public IP
10.x.x.x= private IP
00:00:00:00:00 = eth0
00:00:00:00:01 = eth1
g.g.g.g = default gateway (public router)
8.8.8.8 = dns server
10.1.1.1= cobbler server
----end----

# Using "new" style networking config, by matching networking information to the physical interface's
# MAC-address
%include /tmp/pre_install_network_config


%pre

wget "http://10.1.1.1/cblr/svc/op/trig/mode/pre/system/host1.domain.com" -O /dev/null
# Start pre_install_network_config generated code

# Start of code to match cobbler system interfaces to physical interfaces by their mac addresses
# Start eth1
# Configuring eth1 (00:00:00:00:00:01)
if ifconfig -a | grep -i 00:00:00:00:00:01
then
IFNAME=$(ifconfig -a | grep -i '00:00:00:00:00:01' | cut -d " " -f 1)
echo "network --device=$IFNAME --bootproto=static --ip=10.x.x.x --netmask=255.255.255.0 --gateway=g.g.g.g --nameserver=8.8.8.8 --hostname=host1.domain.com" >> /tmp/pre_install_network_config
fi
# Start eth0
# Configuring eth0 (00:00:00:00:00:00)
if ifconfig -a | grep -i 00:00:00:00:00:00
then
IFNAME=$(ifconfig -a | grep -i '00:00:00:00:00:00' | cut -d " " -f 1)
echo "network --device=$IFNAME --bootproto=static --ip=x.x.x.x --netmask=255.255.255.0 --gateway=g.g.g.g --nameserver=8.8.8.8 --hostname=host1.domain.com" >> /tmp/pre_install_network_config
fi
# End pre_install_network_config generated code

If I use the following two lines in the kickstart file the eth0 device get's activated after the file system is formated and before the packages are isntalled. Same as before making the changes above.

#network
network --device eth1 --bootproto dhcp
network --device eth0 --bootproto dhcp

So enabling one network --device ethx --bootproto dhcp works, either eth0 or 1. Adding the second one to allow for systems that see the eth0/1 device properly fails. I would use $ksdevice= but one of our platforms sees eth0/1 properly when installing CentOS 5.6 but swaps them when installing CentOS6. meaning eth0 becomes eth1 and eth1 becomes eth0. My only other thought is to setup a separate profile for that hardware with ksdevice set to eth1 so the install will work.

[atemp]

[quote]
eclay wrote:
My only other thought is to setup a separate profile for that hardware with ksdevice set to eth1 so the install will work.[/quote]

Ah, you have differnt hardware setups. Well, i do not know anything about cobbler, i like to do my setup manually. But maybe there is a solution to do the whole network config in the %post section for all hardware configs. I would prefer that instead of having multiple kicktstart files/configs.

[canuck15]

[quote]
eclay wrote:
Comparing the results on this system that the install fails on and one that works. I see that both working and non working have Intel 82574L nics but the one that fails is using eth1 as the ksdevice and the one that works uses eth0. What seems to happen is when network manager starts up or activates, it wants to apply a default route to eth0 if one isn't already set for eth0. In the case of the failing system, the default route is set initially on eth1 and it gets clobbered since the one it thinks should be on eth0 is used. It uses the default route as defined by the kickstart file.[/quote]

CentOS6 has a problem with that nic. Not sure if this is related to your problem but worth a look. The solution is to update the kmod driver from 1.2.7 to 1.2.10+. CentOS 6.1 will have v1.2.20 of the e1000e driver but if 6.1 takes as long as it took to get 6.0 out I wouldn't hold my breath.
http://bugs.centos.org/view.php?id=5034

I found an rpm that updated the kmod driver for me. You can also install from source.

for rpm search for "[url=http://elrepo.org/tiki/Packages]kmod-e1000e-1.4.4-1.el6[/url]"

You can get latest source from Intel. Try this link:
http://downloadcenter.intel.com/