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." - https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria#network-attached-storage . iSCSI is a 'supported network-attached storage' protocol.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
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.
Thanks for the quick fix!
Fix confirmed, iSCSI tests are now passing in openQA.