Red Hat Bugzilla – Bug 796193
NIC not configured by default in SSA
Last modified: 2015-11-22 21:57:15 EST
Description of problem:
When installed on a Dell PowerEdge server, the NIC was not configured (DHCP) by default. The /etc/sysconfig/network-scripts/ifcfg-em1 had to be modified slightly to work. Unfortunately I don't recall the default content of said file, but the following settings within the file were configured to make it work:
Version-Release number of selected component (if applicable): 3.2
How reproducible: 100%
Steps to Reproduce:
1. Install the SSA ISO
2. Run ifconfig.
Actual results: NIC not active, no IP address.
Expected results: The server obtains an IP by default in a DHCP environment.
To add to Brian's bug, NTP does not come up either. Consequently the servers all have the wrong time. Whereas typical RHEL 6.2 clients all come up with NTP working, and DHCP edits /etc/ntp.conf to fill in the correct timeserver to use. Storage servers need to have correct time for a variety of reasons (timestamps in metadata kerberos, others I haven't thought of yet)
Created attachment 565668 [details]
screen shots of anaconda install failing because it expected eth0 not em1
I just tried installing RHSSA .iso via PXEboot on Dell PowerEdge 610, it failed. It asked which network interface I wanted to use during install, but then it came back and said eth0 didn't exist, but the interface was named em1. Why oh why did they change the interface names for Dell? But shouldn't anaconda and/or kickstart be able to handle whatever network interface name is used as long as it's an ethernet-type interface?
The workaround is to use a CD/DVD or USB stick. But it's really impractical to do this on a large scale or in an environment where physical access is not practical.
Created attachment 566759 [details]
ks.cfg from SSA 3.2 initrd.img with eth0 hardcoded
Aha, looks like the ks.cfg included in the initrd in the SSA iso is the problem -- it's got eth0 hardcoded:
sed -i -e '/ONBOOT/c ONBOOT=yes\nBOOTPROTO=dhcp' /mnt/sysimage/etc/sysconfig/network-scripts/ifcfg-eth0
I'm not sure what that should be. It might just be that "firstboot --disable" is preventing ifcfg-em0 from getting enabled or similar?
(I haven't included a ks.cfg in the RHS 2.0 isos because at the time I couldn't find a copy of the SSA one easily)
https://access.redhat.com/knowledge/articles/53579 has an article about network interface naming, might want to check that out.
Got very useful information. The bug will be fixed in upcoming releases.
Thanks for everybody's help.
My observation in RHEL 6.2 is that 'Basic Server' or 'Minimal' type installation doesn't start/configure NIC by default. For me, its sort of a bug in RHEL.
As Anthony mentioned, NIC configuration is given to firstboot at first time. This requires X. Neither 'Basic Server'/'Minimal' type nor RH SSA provide/install X by default.
I am figuring other alternative approaches for RH SSA for NIC configuration by default.
Below kickstart configuration will fix
for f in /mnt/sysimage/etc/sysconfig/network-scripts/ifcfg-*; do
if echo $f | grep -q 'ifcfg-lo$'; then
if ! grep -q '^BOOTPROTO' $f; then
echo 'BOOTPROTO="dhcp"' >> $f
if grep -q '^ONBOOT' $f; then
sed -i -e '/^ONBOOT/c ONBOOT="yes"' $f
echo 'ONBOOT="yes"' >> $f
I filed a bug https://bugzilla.redhat.com/show_bug.cgi?id=800850
Update ks used for qa28 spin
Is there a version table for RHS that identifies qa28? RHS-2.0-20120315.4 (currently available via PXE) is still exhibiting the same issue. Screenshots available ...
Please use kickstart file
(In reply to comment #10)
> Is there a version table for RHS that identifies qa28? RHS-2.0-20120315.4
> (currently available via PXE) is still exhibiting the same issue. Screenshots
> available ...
I'd suggest updating to the Beta 1 image (RHS-2.0-20120320.2), but either way sounds like you'll need to make sure you're getting the ks via PXE. It's also in isolinux/initrd.img on the dvd image.
I did try the 20120320.2 build in PXE just to verify that it too does not accommodate the new naming convention of embedded NICs. The workaround for me was to copy the ks file used by the PXE images, modify it to allow an IF named 'em1' and interrupted the PXE boot line to use that modified ks.
Bala, sounds like this needs more work?
(In reply to comment #13)
> I did try the 20120320.2 build in PXE just to verify that it too does not
> accommodate the new naming convention of embedded NICs. The workaround for me
> was to copy the ks file used by the PXE images, modify it to allow an IF named
> 'em1' and interrupted the PXE boot line to use that modified ks.
Could you share the kickstart file you used?
(In reply to comment #15)
> Could you share the kickstart file you used?
Originally I used http://irish.lab.bos.redhat.com/pub/gprfs005.ks for the 20120315.4 build. I later got the kickstart that has the fix (http://irish.lab.bos.redhat.com/pub/RHS2.ks) to work for me.
When I selected the 20120320.2 build the day it appeared in PXE and let it run without interruption, I got the same eth0 failure I'd seen before so it appeared as though the fix was not there yet.
Ok. As long as you use RHS-2.0-iso.ks or modified version of the file, this bug won't appear. You can see how we fixed more bugs in the ks file :)
Fixed in RHS 2.0 beta2.
Verified it on RHS 2.0 RC1
This bug appears fixed to me, who should close it?
Verified state is logical closure as far as we are concerned.