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 710366 - Cannot perform network install directly to iSCSI target available from iBFT.
Summary: Cannot perform network install directly to iSCSI target available from iBFT.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-03 07:55 UTC by Tomasz Kepczynski
Modified: 2011-06-03 13:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-03 13:00:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
tty3 screenshot (26.83 KB, image/png)
2011-06-03 07:55 UTC, Tomasz Kepczynski
no flags Details
tty4 screenshot (25.82 KB, image/png)
2011-06-03 07:56 UTC, Tomasz Kepczynski
no flags Details

Description Tomasz Kepczynski 2011-06-03 07:55:49 UTC
Created attachment 502749 [details]
tty3 screenshot

Description of problem:
Cannot perform network install directly to iSCSI target available from iBFT.

Version-Release number of selected component (if applicable):
Don't know (whatever is available in installation DVD image/installation tree)
Probably 13.21.117

How reproducible:
Always

HW/SW setup:
DELL T610 with two LOMs (Broadcom), both with PXE enabled, they seem to come up as em1 & em2, em1 is used to boot network install and it should be used for nfs.
Portville QT, 2 ports configured as PXE and unused, 2 ports configured as iSCSI, at least one used to connect to iSCSI target at the same subnet at boot time. iSCSI configured from DHCP, gateway provided, CHAP not used.

Steps to Reproduce:
1. Setup as desribed above.
2. Start nfsiso install, pxelinux entry used for boot:
LABEL rhel61s.x86_64
  MENU LABEL RHEL 6.1 Server x86_64
  MENU INDENT 2
  KERNEL RHEL/6.1/x86_64/vmlinuz
  INITRD RHEL/6.1/x86_64/initrd.img
  APPEND ip=dhcp noipv6 lang=en_US keymap=us repo=nfsiso:gklab-63-003.igk.intel.com:/srv/nfs/install/linux/rhel/RHEL-6.1/Server/x86_64/iso stage2=nfs:gklab-63-003.igk.intel.com:/srv/nfs/install/linux/rhel/RHEL-6.1/Server/x86_64/os/images/install.img
  IPAPPEND 2
3. Also tried:
LABEL rhel61s.x86_64.2
  MENU LABEL RHEL 6.1 Server x86_64 (2)
  MENU INDENT 2
  KERNEL RHEL/6.1/x86_64/vmlinuz
  INITRD RHEL/6.1/x86_64/initrd.img
  APPEND ip=dhcp noipv6 lang=en_US keymap=us repo=nfs:gklab-63-003.igk.intel.com:/srv/nfs/install/linux/rhel/RHEL-6.1/Server/x86_64/os
  IPAPPEND 2
  
Actual results:
Installation stops very early with "That directory could bot be mounted from the server" error.
I am not getting shell on tty2.
The screenshots from tty3 & tty4 are attached.
I guess that basically what is happening is that network manager brings up iSCSI interface but seems to not bring up boot interface and both are needed for installation to proceed.

Expected results:
Installtion proceeds.

Additional info:
I guess FCoE may have similar problems.

Comment 1 Tomasz Kepczynski 2011-06-03 07:56:21 UTC
Created attachment 502750 [details]
tty4 screenshot

Comment 3 Radek Vykydal 2011-06-03 09:07:52 UTC
To activate additional device (in your case em1) kickstart has to be used. 

Something like:
network --device=bootif --bootproto=dhcp --activate.
would activate your pxe boot device.

But I suppose you'd want to get the kickstart via em1 then, so you need to set it in options with ksdevice=bootif so that your pxe boot device is activated instead of p5p4 (which was activated in your case because you didn't specify ksdevice and ibft was detected). Your configuration might look like:

APPEND ksdevice=bootif ip=dhcp noipv6 ...

and this command in kickstart:

network --device=ibft --bootproto=dhcp --noipv6 --activate

Comment 4 Tomasz Kepczynski 2011-06-03 10:01:16 UTC
Well, I understand it. The point is that I DON'T want to use kickstart, I want to do fully interactive installation from the network to the target. Is it possible? If not - shouldn't it be?

Comment 5 Radek Vykydal 2011-06-03 12:34:59 UTC
Your configuration is supported only using kickstart which makes the installation not fully interactive. Having only network commands in kickstart would make hostname/network configuration page skipped, and some other pages can be affected too (e.g. Basic/Advanced Storage page is skipped unless ignoredisk --interactive is added into kickstart). If this is not an option for you, you can fill RFE for support of your configuration without kickstart but I am rather pessimistic about it as it would require rather intrusive changes.

In loader text UI we allow to configure and activate only single device interactively. Changing that would require essential changes in fragile code. 
Another option is to activate the iSCSI device in GUI using [Configure Network] button on hostname page, and then (awkwardly) going back to Basic/Advanced Storage screen to configure and activate (using Connect Automatically checkbox) the iSCSI target. The problem here is that the NetworkManager Connection Editor we are using in GUI doesn't have "use iBFT values" option so you'd need to fill the iBFT values manually. Adding iBFT option to Connection Editor may be a way to go from anaconda point of view but I don't know what NM people would say to this and if it is doable.

Comment 6 Tomasz Kepczynski 2011-06-03 12:41:37 UTC
OK, clear on that. I live it up to you to close or keep it if you think RHEL documenation should be updated to explain this limitation.
Do you think it is worthwhile to clone this to Fedora so they can have a look at the issue and decide if it should go into anaconda some time in a future?

Comment 7 Radek Vykydal 2011-06-03 13:00:09 UTC
(In reply to comment #6)

> Do you think it is worthwhile to clone this to Fedora so they can have a look
> at the issue and decide if it should go into anaconda some time in a future?

No need to clone. I'll update respective use case in http://fedoraproject.org/wiki/Anaconda/Network#Missing_GUI_pieces so that I remember.


Note You need to log in before you can comment on or make changes to this bug.