RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 732672 - Need to manually select NIC to continue when installing RHEL 6.1 with kickstart file
Summary: Need to manually select NIC to continue when installing RHEL 6.1 with kicksta...
Keywords:
Status: CLOSED DUPLICATE of bug 731274
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-23 09:42 UTC by Jack Zhou
Modified: 2011-08-25 07:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-25 07:08:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Screenshots and installation logs (160.65 KB, application/zip)
2011-08-24 02:05 UTC, Jack Zhou 		no flags Details
ks file (5.14 KB, text/plain)
2011-08-25 03:28 UTC, Jack Zhou 		no flags Details
View All

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 ***
Note You need to log in before you can comment on or make changes to this bug.