Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1427359 - iSCSI Target discovery during Fedora Rawhide install fails with "Cannot perform discovery. Initiatorname required."
Summary: iSCSI Target discovery during Fedora Rawhide install fails with "Cannot perfo...
Alias: None
Product: Fedora
Classification: Fedora
Component: iscsi-initiator-utils
Version: 26
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Chris Leech
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F26FinalBlocker
TreeView+ depends on / blocked
Reported: 2017-02-28 01:26 UTC by Adam Williamson
Modified: 2017-03-03 23:39 UTC (History)
3 users (show)

Fixed In Version: iscsi-initiator-utils-
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-02-28 18:39:07 UTC
Type: Bug

Attachments (Terms of Use)

Description Adam Williamson 2017-02-28 01:26:48 UTC
Between Fedora-Rawhide-20170208.n.0, when this test run happened:

and Fedora-Rawhide-20170214.n.0, when this one happened:

something seems to have changed in iSCSI target discovery. The 20170208.n.0 test successfully completed iSCSI target discovery (it's marked as 'failed' because of an issue that was going on in Rawhide at the time with ttys, but it has nothing to do with iSCSI - the iSCSI stuff worked fine in that run). The 20170214.n.0 test, and the same iSCSI test for every subsequent Rawhide compose, failed when iSCSI target discovery should have occurred. The screen shows an error message:

"Discovery login rejected. The following error occurred discovering iSCSI targets. Please double check your authorization information and try again.

Cannot perform discovery. Initiatorname required."

Note that the test *does* provide an initiator name; you can see it also in the screenshot, iqn.2016-06.local.domain:support.target1 . The test's behaviour did not change at all between 20170208 (when this worked) and 201702014 (when it failed). Note there were no successful composes between 20170208 and 20170214, hence the gap.

The first part of the error is a generic anaconda error message shown whenever iSCSI target discovery fails for any reason. The specific error message is "Cannot perform discovery. Initiatorname required.", which comes from iscsi-initiator-utils. Specifically I think it comes from here:

the exact error text actually occurs twice in that file, but the other occurrence is in a function named `discovery_isns`, and I don't think iSNS is involved here.

I note that the error condition immediately follows this line:

	*rc = request_initiator_name(tmo);

which was changed in this commit:

which seems to have already been found to cause some problems, at least on the basis of this commit:

so my guess is this is another case of that timeout change causing problems. The iscsi-initiator-utils package was updated on 2017-02-09:

that build bumped the package from a mid-2016 git snapshot to a new release that included the timeout commit, and it falls exactly in the time frame when the bug started happening. So it seems like a pretty strong suspect. Note that there has been another iscsi-initiator-utils package build since then which includes the 81f52b082f5b111d084d5c349bdef7077e23d650 commit, and we're still seeing this bug in current Rawhide nightly tests, so that one obviously doesn't fix this problem.

Proposing as a Final release blocker, per criterion "The installer must be able to detect (if possible) and install to supported network-attached storage devices." - . iSCSI is a 'supported network-attached storage' protocol.

Comment 1 Fedora End Of Life 2017-02-28 12:28:05 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 2 Chris Leech 2017-02-28 18:39:07 UTC
This looks to be the same timeout regression with discovery commands, but manifesting through the libiscsi interfaces used by blivet, while just the iscsiadm tool was fixed previously.

Testing with an updates.img containing the new build seems to work.

Comment 3 Adam Williamson 2017-02-28 18:53:58 UTC
Thanks for the quick fix!

Comment 4 Adam Williamson 2017-03-03 23:39:19 UTC
Fix confirmed, iSCSI tests are now passing in openQA.

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