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 bugzilla.redhat.com.
Bug 1627757
| Summary: | The installer failed to use an iscsi target create by targetcli | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | lnie <lnie> | ||||||||||||||
| Component: | anaconda | Assignee: | Radek Vykydal <rvykydal> | ||||||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||
| Priority: | unspecified | ||||||||||||||||
| Version: | 29 | CC: | anaconda-maint-list, awilliam, gmarr, jonathan, kellin, lnie, robatino, rvykydal, vanmeeuwen+fedora, vponcova, wwoods | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Target Release: | --- | ||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||
| OS: | Unspecified | ||||||||||||||||
| Whiteboard: | AcceptedBlocker | ||||||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||
| Last Closed: | 2018-09-25 11:02:38 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: | |||||||||||||||||
| Bug Depends On: | |||||||||||||||||
| Bug Blocks: | 1517013 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Created attachment 1482340 [details]
anaconda.log
Created attachment 1482341 [details]
storage.log
Proposed as a Blocker for 29-final by Fedora user lnie using the blocker tracking app because: This affects the final criteria: The installer must be able to detect (if possible) and install to supported network-attached storage devices. openQA iSCSI test is working: https://openqa.fedoraproject.org/tests/277611 it 'fails' because networking doesn't work post-install in that test for some reason, but the actual iSCSI install and boot works... (In reply to Adam Williamson from comment #4) > openQA iSCSI test is working: > > https://openqa.fedoraproject.org/tests/277611 > > it 'fails' because networking doesn't work post-install in that test for > some reason, but the actual iSCSI install and boot works... You are using the target created by tgtadm,right? I can tell it as old tgtadm doesn't support discovery authentication, and the openqa test dosen't test discovery authentication,while dose test login authentication.And I've checked,the tgtadm WFM too,as shown in the attached screenshot:)So...,I'm not sure this is whose fault(reported a targetcli bug earlier #1627995),but anaconda dose can't login the iscsi target created by targetcli.BTW,if I set discovery authentication for the targetcli target,anaconda will be unable to discover the target Created attachment 1482580 [details]
screenshot
Created attachment 1482581 [details]
anaconda.log
Created attachment 1482582 [details]
storage.log
OK, thanks for the clarification :) Discussed during the 2018-09-17 blocker review meeting: [1] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria: "The installer must be able to detect (if possible) and install to supported network-attached storage devices", iSCSI is a 'supported' network-attached protocol. We will look further into when this does and does not happen. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-17/f29-blocker-review.2018-09-17-16.02.txt Connecting to target created by targetcli works for me.
I think the problem is target ACLs not being set for installer initiator (or not using initiator name defined in target's ACL in installer).
Target ACLs from the Description:
o- acls
............................................................................................................ [ACLs: 1]
| o- iqn.1994-05.com.redhat:71fc25b8ad3
don't contain installer's initiator name (from storage.log, comment #8):
14:56:12,048 INF blivet: Setting up iSCSI initiator name iqn.1994-05.com.redhat:c292a74a4b62
Unlike tgtadm, targetcli doesn't allow non-authenticated access to target without setting ACLs for the initiator by default. (It can be achieved by using demo mode.)
So this seems like misconfiguration issue to me.
(In reply to Radek Vykydal from comment #11) > Unlike tgtadm, targetcli doesn't allow non-authenticated access to target > without setting ACLs for the initiator by default. (It can be achieved by > using demo mode.) My fault,I know of that,but failed to notice that anaconda's iscsi initiator name is different with the initiator system's /etc/iscsi/initiatorname.iscsi(The test installer is booted with VM),and I find it isn't owned by any package,is that the wanted behavior? [root@192 lnie]# rpm -qf /etc/iscsi/initiatorname.iscsi file /etc/iscsi/initiatorname.iscsi is not owned by any package > Connecting to target created by targetcli works for me. I've checked,if you change anaconda's iscsi initiator name to the /etc/iscsi/initiatorname.iscsi one manually(or create a target with anaconda's iscsi initiator name,presumably) anaconda will connect to the target,ALA you don't use the authentication,but if you want to apply authentication,you will see #bz1632656 (In reply to lnie from comment #12) > (In reply to Radek Vykydal from comment #11) > > > Unlike tgtadm, targetcli doesn't allow non-authenticated access to target > > without setting ACLs for the initiator by default. (It can be achieved by > > using demo mode.) > My fault,I know of that,but failed to notice that anaconda's iscsi initiator > name > is different with the initiator system's /etc/iscsi/initiatorname.iscsi(The > test installer is booted with VM),and I find it isn't owned by any > package,is that the wanted behavior? Yes, installer environment has its own initiator name generated (or defined in GUI or in kickstart). > > Connecting to target created by targetcli works for me. > > I've checked,if you change anaconda's iscsi initiator name to the > /etc/iscsi/initiatorname.iscsi one manually(or create a target with > anaconda's iscsi initiator name,presumably) anaconda will connect to the > target,ALA you don't use the authentication,but if you want to apply > authentication,you will see #bz1632656 We'll look into it. |
Created attachment 1482339 [details] screenshot Description of problem: create a iscsi target using targetcli /iscsi> ls o- iscsi .............................................................................................................. [Targets: 1] o- iqn.2018-01.com.example:target ...................................................................................... [TPGs: 1] o- tpg1 ................................................................................................. [no-gen-acls, no-auth] o- acls ............................................................................................................ [ACLs: 1] | o- iqn.1994-05.com.redhat:71fc25b8ad3 ..................................................................... [Mapped LUNs: 1] | o- mapped_lun0 ............................................................................... [lun0 fileio/testfile (rw)] o- luns ............................................................................................................ [LUNs: 1] | o- lun0 .......................................................... [fileio/testfile (/tmp/testiscsi.img) (default_tg_pt_gp)] o- portals ...................................................................................................... [Portals: 1] o- 0.0.0.0:3260 ....................................................................................................... [OK] [root@192 lnie]# iscsiadm -m node -T iqn.2018-01.com.example:target -l Logging in to [iface: default, target: iqn.2018-01.com.example:target, portal: 10.66.128.196,3260] (multiple) Login to [iface: default, target: iqn.2018-01.com.example:target, portal: 10.66.128.196,3260] successful. [root@192 lnie]# iscsiadm -m node -T iqn.2018-01.com.example:target -u Logging out of session [sid: 1, target: iqn.2018-01.com.example:target, portal: 10.66.128.196,3260] Logout of [sid: 1, target: iqn.2018-01.com.example:target, portal: 10.66.128.196,3260] successful. As shown in the attached packaging.log,tough iscsiadm can login the target, the installer claims::48:51,344 WRN blivet: iSCSI: could not log into iqn.2018-01.com.example:target: Failed to call Login method on /org/freedesktop/UDisks2/Manager with ('iqn.2018-01.com.example:target', 1, '10.66.128.196', 3260, 'default', {'node.startup': <'automatic'>}) arguments: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Login failed: initiator reported error (24 - iSCSI login failed due to authorization failure) Version-Release number of selected component (if applicable): Fedora-Server-dvd-x86_64-29-20180909.n.0.iso How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: