Bug 733208

Summary: Can't install RHEL 5.7 in the machine with multiple NICs
Product: Red Hat Enterprise Linux 5 Reporter: Jack Zhou <zhoudaxia>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED NOTABUG QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.7CC: akozumpl, rvykydal
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-25 11:07:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshots and logs
none
ks file we used none

Description Jack Zhou 2011-08-25 06:43:26 UTC
Created attachment 519767 [details]
screenshots and logs

Description of problem:
  When installing RHEL 5.7 in the machine with multiple NICs (Onboard NIC has two port eth0 and eth1. Extra NIC plugged by me has two port eth2 and eth3) based on NFS. the process hang up at the beginning of installation. eth0 can't get IP via DHCP. Thus, the NFS path of the installation tree can't be mounted to local machine.
  In our experiment environment, eth0 connects to the network. but eth1, eth2, eth3 don't. The installation process is executed by means of NFS. The installation tree locate in NFS server.
  

Version-Release number of selected component (if applicable):
Anaconda for RHEL 5.7 x86_64

How reproducible:
always

Steps to Reproduce:
1. Setup RHEL 5.7 installation tree in the NFS server.
2. Plug extra NIC to the target machine. Let eth0 connect to the network.
3. Install RHEL 5.7 to the target machine.
  
Actual results:
the process hang up at the beginning of installation. eth0 can't get IP via DHCP.

Expected results:
RHEL 5.7 can be installed into target machine with multiple NICs.


Additional info:
  If the target machine just have onboard NIC ( That means we don't plug extra NIC), RHEL 5.7 can be installed successfully base on NFS.
  In the multiple NICs environment (onboard NIC and extra plugged NIC), let eth1 connect to the network, the installation process based on NFS will also hang up.
  In the multiple NICs environment,the installation process base on local DVD-ROM will be executed successfully.

Comment 1 Jack Zhou 2011-08-25 06:44:51 UTC
Created attachment 519768 [details]
ks file we used

Comment 2 Ales Kozumplik 2011-08-25 06:55:58 UTC
One of the screenshots indicates that there's no link on eth0. Maybe when you plugin the extra NICs they become eth0 and eth1 and the onboard NIC is eth2?

Comment 3 Jack Zhou 2011-08-25 10:35:20 UTC
(In reply to comment #2)
> One of the screenshots indicates that there's no link on eth0. Maybe when you
> plugin the extra NICs they become eth0 and eth1 and the onboard NIC is eth2?

  But when I changed command "network --bootproto dhcp --device eth0" into "network --bootproto dhcp" in ks file and run the case,the issue didn't disappear. According to official description, anaconda can find the correct NIC automatically if command "network --bootproto dhcp" is in ks file.
  Can I modify ks file to make anaconda find the correct NIC automatically in the mutiple NICs environment? If I can, how to do it?

Comment 4 Ales Kozumplik 2011-08-25 11:07:40 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > One of the screenshots indicates that there's no link on eth0. Maybe when you
> > plugin the extra NICs they become eth0 and eth1 and the onboard NIC is eth2?
> 
>   But when I changed command "network --bootproto dhcp --device eth0" into
> "network --bootproto dhcp" in ks file and run the case,the issue didn't
> disappear. According to official description, anaconda can find the correct NIC
> automatically if command "network --bootproto dhcp" is in ks file.

Can you please point to where you see this described? What I see in the installation guide is:

"If the installation does require networking and network information is not provided in the kickstart file, the installation program assumes that the installation should be done over eth0 via a dynamic IP address [...]"

>   Can I modify ks file to make anaconda find the correct NIC automatically in
> the mutiple NICs environment? If I can, how to do it?

I am not aware of a way this is possible in rhel5, you have to supply the correct ethernet device. Closing this not a bug, if you are convinced you are pointing Anaconda to the correct NIC with a link, consider reopening and attaching all the log files from under /tmp as text files to this bug in that case.

Comment 5 Radek Vykydal 2011-08-25 12:31:55 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > One of the screenshots indicates that there's no link on eth0. Maybe when you
> > plugin the extra NICs they become eth0 and eth1 and the onboard NIC is eth2?
> 
>   But when I changed command "network --bootproto dhcp --device eth0" into
> "network --bootproto dhcp" in ks file and run the case,the issue didn't
> disappear. According to official description, anaconda can find the correct NIC
> automatically if command "network --bootproto dhcp" is in ks file.
>   Can I modify ks file to make anaconda find the correct NIC automatically in
> the mutiple NICs environment? If I can, how to do it?

You can use mac address to specify the device.

Comment 6 Jack Zhou 2011-08-29 09:25:25 UTC
(In reply to comment #5)
> 
> You can use mac address to specify the device.

  When I add option "--device=00:1A:64:B3:10:68" (it is eth0's mac address) into network command in the ks file, it looks as follow:
network --device=00:1A:64:B3:10:68 --bootproto dhcp
  the installation hang up and shows that parsing kickstart configuration error, the provided network interface 00:1A:64:B3:10:68 does not exist.
  It seems that the syntax "--device=00:1A:64:B3:10:68" is wrong. How can I use mac address to specify the device?

Comment 7 Radek Vykydal 2011-08-29 13:00:08 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > 
> > You can use mac address to specify the device.
> 
>   When I add option "--device=00:1A:64:B3:10:68" (it is eth0's mac address)
> into network command in the ks file, it looks as follow:
> network --device=00:1A:64:B3:10:68 --bootproto dhcp
>   the installation hang up and shows that parsing kickstart configuration
> error, the provided network interface 00:1A:64:B3:10:68 does not exist.
>   It seems that the syntax "--device=00:1A:64:B3:10:68" is wrong. How can I use
> mac address to specify the device?

My apologies, this works only in rhel 6. In rhel 5 you have to use ksdevice boot option - you can use either device name, mac address, or "link" (select device having active link) to specify the device.

Comment 8 Jack Zhou 2011-08-31 01:51:10 UTC
(In reply to comment #7)
 
> My apologies, this works only in rhel 6. In rhel 5 you have to use ksdevice
> boot option - you can use either device name, mac address, or "link" (select
> device having active link) to specify the device.

  When I add "ksdevice=eth0" into ks file as follow:
bootloader --location=mbr --append="ksdevice=eth0 rhgb quiet"
  The eth0 is active NIC. In this case, the installation will popup a multiple NICs selection interface. Choose the active NIC, the installation will succeed.

  Basically, this method solve our problem. But another question is that why the multi-NICs selection interface appear after I specify the active NIC through "ksdevice=eth0"? (In this case the network command is "network --bootproto dhcp") It is known that installation based on ks file should be unattended mode.

Comment 9 Radek Vykydal 2011-08-31 10:00:49 UTC
By boot option I mean ksdevice from http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-kickstart2-startinginstall.html (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s2-x86-starting-bootopts.html) not kickstart bootloader --append option.

One more note - I assumed that you are not fetching kickstart over network. In this case ksdevice would be just used for missing --device specification of network kickstart command (where mac address or "link" specification can't be used) and network would be configured according to --bootproto setting. If you are getting kickstart over network, it has to be activated before downloading kickstart so you have to specify also device configuration as boot option (e.g. ip=dhcp) if you want to prevent asking for configuration in UI.