Created attachment 502749 [details]
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)
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:
MENU LABEL RHEL 6.1 Server x86_64
MENU INDENT 2
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
3. Also tried:
MENU LABEL RHEL 6.1 Server x86_64 (2)
MENU INDENT 2
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
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.
I guess FCoE may have similar problems.
Created attachment 502750 [details]
To activate additional device (in your case em1) kickstart has to be used.
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
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?
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.
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?
(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.