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 1271938 - [RHEL-7.2-Snapshot-3] Bootloader insertion exception during iSCSI installation without 'ip=ibft'
Summary: [RHEL-7.2-Snapshot-3] Bootloader insertion exception during iSCSI installatio...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-15 06:34 UTC by Sujith
Modified: 2016-02-24 20:36 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-24 20:36:11 UTC
Target Upstream Version:
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1269195 0 high CLOSED AttributeError: 'NoneType' object has no attribute 'name' 2021-02-22 00:41:40 UTC

Internal Links: 1269195

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.
Note You need to log in before you can comment on or make changes to this bug.