Bug 732672

Summary: Need to manually select NIC to continue when installing RHEL 6.1 with kickstart file
Product: Red Hat Enterprise Linux 6 Reporter: Jack Zhou <zhoudaxia>
Component: anacondaAssignee: Radek Vykydal <rvykydal>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1CC: 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 07:08:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Screenshots and installation logs
none
ks file none

Description Jack Zhou 2011-08-23 09:42:32 UTC 
Description of problem:
  When using kickstart file to install RHEL 6.1 (x86_64) through text mode with multiple NICs in the target machine, a multi-NICs selection interface will be informed at the beginning of the os installation process. Select a NIC, the installation process will continue and succeed.
  But for the installation of previous RHEL version (6.0, 5.x), the multi-NICs selection interface isn't informed at all. It will auto activate the appropriate NIC and the installation process is completely unattended mode.
  In our experiment environment, there are two NICs on the target machine. NIC eth0 have been connected to a network, but eth1 doesn'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 13.21.117 for x86_64

How reproducible:
Always

Steps to Reproduce:
1. Setup installation tree on the NFS server.
2. At least two NICs are setuped in the target machine.
3. Install RHEL 6.1 x86_64 through text mode based on NFS.
  
Actual results:
  A multi-NICs selection interface will appeared at the beginning of the os installation process.

Expected results:
  RHEL 6.1 installation can be completed in kickstart mode and no need any manual interrupt.

Additional info:
  The anaconda log shows "iBFT doesn't couldn't provide valid NIC MAC address" in the step of multi-NICs selection. According to this message, we tried to eliminate this problem by updating kickstart file as follows.
  option 1. add "network --activate --bootproto=dhcp --device=eth0" in ks file according to RHEL6.1 installation guide.
  option 2: add kernel parameter "ksdevice=eth0 ip=dhcp" in ks file as follow:
bootloader --location=partition --driveorder=sda --append="ksdevice=eth0 ip=dhcp crashkernel=auto rhgb quiet"
  option 3: configure iSCSI, then add "network --bootproto=ibft --device=00:1A:64:B3:10:68" in ks file.
  option 4: add "network --bootproto=ibft --device=eth0" in ks file.
  option 4: add "network --bootproto=dhcp --device=00:1A:64:B3:10:68" in ks file.
  All of these options can not solve the issue. Also, specifying --device=eth1 can not fix this issue.
Comment 2 Radek Vykydal 2011-08-23 11:17:44 UTC 
Could you please attach these log files:
/tmp/anaconda.log,
/tmp/syslog,
/tmp/ifcfg.log,
and kickstart file used (if any).
You can gather them during installation on tty2 using scp or cp (or they are copied to installed system into /var/log/anaconda, the syslog file is named anaconda.syslog there). It is really strange that none of the options you tried prevented device selection dialog. It seems like activation of device specified in kickstart or boot command line failed, I'll be able to say more when I see the logs.
Comment 3 Jack Zhou 2011-08-24 02:05:56 UTC 
Created attachment 519545 [details]
Screenshots and installation logs
Comment 4 Jack Zhou 2011-08-24 02:08:27 UTC 
(In reply to comment #2)
> Could you please attach these log files:
> /tmp/anaconda.log,
> /tmp/syslog,
> /tmp/ifcfg.log,
> and kickstart file used (if any).
> You can gather them during installation on tty2 using scp or cp (or they are
> copied to installed system into /var/log/anaconda, the syslog file is named
> anaconda.syslog there). It is really strange that none of the options you tried
> prevented device selection dialog. It seems like activation of device specified
> in kickstart or boot command line failed, I'll be able to say more when I see
> the logs.

Sorry. When reporting the bug, I attached the logs. Maybe they aren't uploaded successfully. I re-attached the logs.
Comment 5 Radek Vykydal 2011-08-24 10:58:47 UTC 
Thanks for the logs, I'd need the kickstart file actually used for the installation (ks=file:///wQdhA9Ucfe, can be gathered during install as /tmp/ks.cfg I think), not the file generated by anaconda (anaconda-ks.cfg).

I have one idea - isn't the network command in your kickstart file preceding the nfs command? If so, and swapping the lines fixes the issue (by actually applying the kickstart network command), this could be a duplicate of bug #731274.

The iBFT not being detected might be another issue, you can issue iscsiadm -m fw in tty2 to read the configuration of iBFT anaconda is seeing and check that iBFT is correctly configured.
Comment 6 Jack Zhou 2011-08-25 03:28:31 UTC 
Created attachment 519758 [details]
ks file
Comment 7 Jack Zhou 2011-08-25 03:29:11 UTC 
(In reply to comment #5)
> Thanks for the logs, I'd need the kickstart file actually used for the
> installation (ks=file:///wQdhA9Ucfe, can be gathered during install as
> /tmp/ks.cfg I think), not the file generated by anaconda (anaconda-ks.cfg).
> 
> I have one idea - isn't the network command in your kickstart file preceding
> the nfs command? If so, and swapping the lines fixes the issue (by actually
> applying the kickstart network command), this could be a duplicate of bug
> #731274.
> 
> The iBFT not being detected might be another issue, you can issue iscsiadm -m
> fw in tty2 to read the configuration of iBFT anaconda is seeing and check that
> iBFT is correctly configured.

The ks file has been attached.
Comment 8 Radek Vykydal 2011-08-25 07:08:43 UTC 
> 
> I have one idea - isn't the network command in your kickstart file preceding
> the nfs command? If so, and swapping the lines fixes the issue (by actually
> applying the kickstart network command), this could be a duplicate of bug
> #731274.
> 

It is the "network" command preceding the "text" command. A workaround is to change the order. Marking as duplicate of bug #731274 which should be fixed in rhel 6.2.

*** This bug has been marked as a duplicate of bug 731274 ***