Bug 1271938

Summary: [RHEL-7.2-Snapshot-3] Bootloader insertion exception during iSCSI installation without 'ip=ibft'
Product: Red Hat Enterprise Linux 7 Reporter: Sujith <sujith_pandel>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.2CC: linux-bugs, rvykydal, sreekanth_reddy, sujith_pandel, tgummels
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: 2016-02-24 20:36:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
anaconda.log
none
storage.log none

Description Sujith 2015-10-15 06:34:07 UTC
Created attachment 1083138 [details]
anaconda.log

Description of problem:
RHEL-7.2-Snapshot-3 is being installed on an iSCSI LUN using DVD, but without passing the boot parameter 'ip=ibft' nor 'rd.iscsi.ibft=1'. 
iSCSI LUN onto which the installation is to be done is manually discovered after enabling the proper network interface. 
During bootloader insertion phase, we can see an exception thrown showing that it failed to find a suitable stage1 device.

Version-Release number of selected component (if applicable):
anaconda-21.48.22.50-1

How reproducible:
Always.

Steps to Reproduce:
1. Setup a server with a NIC configured for iSCSI installation. Disable all local disks. 
2. Start the server and verify successful login to iSCSI target during POST. 
3. Start RHEL-7.2-Snapshot-3 installation without passing boot parameter 'ip=ibft' or 'rd.iscsi.ibft=1'
4. Enable proper network interface and manually discover the iSCSI LUN.
5. Choose "Automatic Partitioning" and start the installation. Note that only iSCSI disk is available.
6. In bootloader insertion phase, an exception is thrown showing failure in finding a suitable stage1 device.

Actual results:
Installation is aborted.

Expected results:
Installation should be successful(?). Please confirm.

Additional info:
* This error is not seen when installation is started by giving the boot parameter 'ip=ibft'.

* Issue is not seen with RHEL-7.1 and RHEL-7.0 

Seems related to an internal BZ#1164195 which contributed the following patches in anaconda:
Patch-1: https://github.com/rhinstaller/anaconda/commit/610bf3f050bfa2d15375f778e5336f4d26b4198c
Patch-2: https://github.com/rhinstaller/anaconda/commit/3c1931ca8e2ce00e9b13939ec1e0693e38244424

These patches are to disable /boot to be on iSCSI disks, unless it is iBFT. 
Does that mean an iSCSI installation should always be started with boot parameter 'ip=ibft' from RHEL-7.2 onwards? 
Please confirm this behavior.

Comment 1 Sujith 2015-10-15 06:35:37 UTC
Created attachment 1083139 [details]
storage.log

Comment 3 Radek Vykydal 2015-10-15 10:23:04 UTC
(In reply to Sujith from comment #0)
 
> Seems related to an internal BZ#1164195 which contributed the following
> patches in anaconda:
> Patch-1:
> https://github.com/rhinstaller/anaconda/commit/
> 610bf3f050bfa2d15375f778e5336f4d26b4198c
> Patch-2:
> https://github.com/rhinstaller/anaconda/commit/
> 3c1931ca8e2ce00e9b13939ec1e0693e38244424
> 
> These patches are to disable /boot to be on iSCSI disks, unless it is iBFT. 
> Does that mean an iSCSI installation should always be started with boot
> parameter 'ip=ibft' from RHEL-7.2 onwards? 
> Please confirm this behavior.

Yes, but... I'll try to be more precise: It means that for installation with /boot on iSCSI disk, the disk must be automatically attached by Anaconda based on the target configuration set in iBFT. 
Regarding the need of ip=ibft boot parameter: to successfully auto-attach iBFT target, a network device to access the target must be configured early enough (well, in most cases). This can (and in majority of cases should) be achieved by ip=ibft boot option, but it would work also when an interface is activated by other means (for example a device activated to fetch kickstart, or device set up to be activated in installer by kickstart).

Comment 4 Sujith 2015-10-15 12:20:28 UTC
(In reply to Radek Vykydal from comment #3)
> Yes, but... I'll try to be more precise: It means that for installation with
> /boot on iSCSI disk, the disk must be automatically attached by Anaconda
> based on the target configuration set in iBFT. 

So.. iSCSI disks should automatically be mounted/detected during installation if /boot is to be on iSCSI disk. 
This can be due to 'ip=ibft' or if PXE (or other cases you mentioned in c#3) then it can auto-detect iSCSI LUN.

I have couple of questions, if you don't mind..
* Is this behavior applicable in case of FCoE installation also?

* Is this behavior already documented? or Will this be documented for RHEL-7.2, to point out the difference between previous RHEL-7.x and RHEL-7.2?

Thanks!
Sujith

Comment 5 Radek Vykydal 2015-10-20 08:17:45 UTC
(In reply to Sujith from comment #4)
> (In reply to Radek Vykydal from comment #3)
> > Yes, but... I'll try to be more precise: It means that for installation with
> > /boot on iSCSI disk, the disk must be automatically attached by Anaconda
> > based on the target configuration set in iBFT. 
> 
> So.. iSCSI disks should automatically be mounted/detected during
> installation if /boot is to be on iSCSI disk. 
> This can be due to 'ip=ibft' or if PXE (or other cases you mentioned in c#3)
> then it can auto-detect iSCSI LUN.
> 
> I have couple of questions, if you don't mind..
> * Is this behavior applicable in case of FCoE installation also?
> 

No, just iSCSI installations.

> * Is this behavior already documented? or Will this be documented for
> RHEL-7.2, to point out the difference between previous RHEL-7.x and RHEL-7.2?

Should be documented in scope of the bug 1164195 introducing the change, I'll clone the BZ for installation guide.

Comment 6 Radek Vykydal 2015-10-20 08:18:16 UTC
(In reply to Radek Vykydal from comment #5)
 
> Should be documented in scope of the bug 1164195 introducing the change,
> I'll clone the BZ for installation guide.

bug 1273316

Comment 7 Sujith 2015-10-21 04:29:00 UTC
Both of these bug reports are internal and we don't have access to it.
Please update us with the status of these bugs, once documentation changes are finalized.

Thanks!
Sujith

Comment 8 Radek Vykydal 2015-10-21 07:26:02 UTC
(In reply to Sujith from comment #7)
> Both of these bug reports are internal and we don't have access to it.
> Please update us with the status of these bugs, once documentation changes
> are finalized.

I asked for opening the bugs for access and added you to CC of the bugs which should make them accessible for you in the meantime.

Comment 9 RHEL Program Management 2016-02-24 20:36:11 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.