Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Cannot perform network install directly to iSCSI target available from iBFT.|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Tomasz Kepczynski <tomasz.kepczynski>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED NOTABUG||QA Contact:||Release Test Team <release-test-team>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-06-03 09:00:09 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Tomasz Kepczynski 2011-06-03 03:55:49 EDT
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 03:56:21 EDT
Created attachment 502750 [details] tty4 screenshot
Comment 3 Radek Vykydal 2011-06-03 05:07:52 EDT
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 06:01:16 EDT
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 08:34:59 EDT
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 08:41:37 EDT
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 09:00:09 EDT
(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.