Bug 1271938 - [RHEL-7.2-Snapshot-3] Bootloader insertion exception during iSCSI installation without 'ip=ibft'
[RHEL-7.2-Snapshot-3] Bootloader insertion exception during iSCSI installatio...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda (Show other bugs)
7.2
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-15 02:34 EDT by Sujith
Modified: 2016-02-24 15:36 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-24 15:36:11 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log (16.82 KB, text/plain)
2015-10-15 02:34 EDT, Sujith
no flags Details
storage.log (154.57 KB, text/plain)
2015-10-15 02:35 EDT, Sujith
no flags Details

  None (edit)
Description Sujith 2015-10-15 02:34:07 EDT
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 02:35 EDT
Created attachment 1083139 [details]
storage.log
Comment 3 Radek Vykydal 2015-10-15 06:23:04 EDT
(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 08:20:28 EDT
(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 04:17:45 EDT
(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 04:18:16 EDT
(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 00:29:00 EDT
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 03:26:02 EDT
(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 Product and Program Management 2016-02-24 15:36:11 EST
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

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