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 1396935 - there is no iscsi disks in list after login
Summary: there is no iscsi disks in list after login
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-21 08:51 UTC by lnie
Modified: 2017-09-22 07:52 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-22 07:52:10 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
picture1 (35.07 KB, image/png)
2016-11-21 08:51 UTC, lnie 		no flags Details
picture2 (120.97 KB, image/png)
2016-11-21 08:52 UTC, lnie 		no flags Details
screenshot of the issue (82.78 KB, image/png)
2016-11-21 08:53 UTC, lnie 		no flags Details
anaconda.log (28.99 KB, text/plain)
2016-11-21 08:54 UTC, lnie 		no flags Details
packaging.log (7.64 KB, text/plain)
2016-11-21 08:54 UTC, lnie 		no flags Details
program.log (17.93 KB, text/plain)
2016-11-21 08:55 UTC, lnie 		no flags Details
storage.log (63.86 KB, text/plain)
2016-11-21 08:55 UTC, lnie 		no flags Details
syslog (260.90 KB, text/plain)
2016-11-21 08:56 UTC, lnie 		no flags Details
x.log (17.65 KB, text/plain)
2016-11-21 08:56 UTC, lnie 		no flags Details
picture3 (135.73 KB, image/png)
2016-11-23 04:10 UTC, lnie 		no flags Details
journal when try to create a target using tgtadm with the default var_t disk type (197.01 KB, text/x-vhdl)
2016-11-23 04:23 UTC, lnie 		no flags Details
View All

Description lnie 2016-11-21 08:51:58 UTC 
Created attachment 1222321 [details]
picture1

Description of problem:
try to create a VM using iscsi disk,but after login the target there is no iscsi disk in the list,so I can't use the disk to install the system.The thing is: iscsiadm can successfully login,and the installer can recognizes the disk(picture1).If you try "Add iscsi target" again,you will get picture2.
[root@localhost lnie]# iscsiadm -m node -p 192.168.122.152 -l
Logging in to [iface: default, target: iqn.2016-09.example.com:test-target, portal: 192.168.122.152,3260] (multiple)
Login to [iface: default, target: iqn.2016-09.example.com:test-target, portal: 192.168.122.152,3260] successful.

FYI: I created the iscsi target using tgtadm,as targetcli-created target is unusable due to #1396352 

Version-Release number of selected component (if applicable):
f25-rc1.3-x86_64

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 lnie 2016-11-21 08:52:48 UTC 
Created attachment 1222322 [details]
picture2
Comment 2 lnie 2016-11-21 08:53:28 UTC 
Created attachment 1222323 [details]
screenshot of the issue
Comment 3 lnie 2016-11-21 08:54:15 UTC 
Created attachment 1222324 [details]
anaconda.log
Comment 4 lnie 2016-11-21 08:54:55 UTC 
Created attachment 1222326 [details]
packaging.log
Comment 5 lnie 2016-11-21 08:55:26 UTC 
Created attachment 1222328 [details]
program.log
Comment 6 lnie 2016-11-21 08:55:58 UTC 
Created attachment 1222329 [details]
storage.log
Comment 7 lnie 2016-11-21 08:56:24 UTC 
Created attachment 1222330 [details]
syslog
Comment 8 lnie 2016-11-21 08:56:50 UTC 
Created attachment 1222331 [details]
x.log
Comment 9 Samantha N. Bueno 2016-11-21 19:03:31 UTC 
16:41:19,435 DEBUG blivet: iSCSI: skipping discovery of 192.168.122.152:3260 due to active nodes

I might be misunderstanding something here, but it looks like you've already logged into the iSCSI node from the shell using iscsiadm manually. Blivet isn't going to retry discovery since that can corrupt credentials stored for the node.

Don't use iscsiadm manually. Just try adding the iSCSI target from the specialized storage spoke and see what happens.
Comment 10 lnie 2016-11-22 02:42:49 UTC 
I use iscsiadm to test whether the target works fine,after this bug happens,not before.And to be clear, I have re-tested.The skipping thing happens when you try to login again,and you will see picture2 this time,just as described.
Comment 11 Radek Vykydal 2016-11-22 07:54:28 UTC 
According to logs the iscsi targets were (supposedly in GUI) discovered and login succeeded.

16:23:20,420 DEBUG blivet: discovered iSCSI node: iqn.2016-09.example.com:test-target
16:23:34,475 INFO blivet: iSCSI: logged into iqn.2016-09.example.com:test-target at 192.168.122.152:3260 through default
16:23:34,683 INFO blivet: DeviceTree.populate: ignored_disks is [] ; exclusive_disks is []
16:23:34,800 DEBUG blivet: protected device spec LABEL=Fedora-WS-dvd-x86_64-25 resolved to sr0
16:23:34,815 DEBUG blivet: protected device spec /dev/zram0 resolved to None
16:23:34,829 INFO blivet: devices to scan: ['sda', 'sr0', 'sdb', 'sdc', 'loop0', 'loop1', 'loop2', 'live-rw', 'live-base']

Note sdb and sdc disks that are later scanned and recognized as iSCSI disks.
I don't see any relevant error in the logs. Also iSCSI discovery and logging works fine for me with F25 rc1.3.

So the problem seems to be you are not seeing the disks in UI.
Just to be sure, to be able to select an iSCSI disk in Device Selection screen, it has to bee checked in the list of discovered disks in "Add a disk..." screen where the discovery and logging in happens.
Comment 12 Radek Vykydal 2016-11-22 08:38:54 UTC 
On the other hand, picture2 indicates that no disks were really displayed in the list (in the background).
And I was checking with Fedora Server, WS Live image even crashed for me when trying to add iscsi target.
Comment 13 Radek Vykydal 2016-11-22 09:08:59 UTC 
(In reply to Radek Vykydal from comment #12)
> And I was checking with Fedora Server, WS Live image even crashed for me
> when trying to add iscsi target.

Installing storaged-iscsi seems to fix the crash and discovery and login then works for me.
Comment 14 lnie 2016-11-23 04:09:24 UTC 
Seems that I have found the problem:I have set the type of the iscsi disk to abrt_var_run_t,and the disks will show up if I set the type to tgtd_var_lib_t.
My fault,I used the target I created sometime before,and there is AVC denial when I created it,then I changed the type to abrt_var_run_t,as suggested(picture3)
I'm not familiar with selinux policy,so I'm not sure it's a bug to hidden the disks.
#1396908 is reproducible with both target disks set to tgtd_var_lib_t

And there is something confused me :
If you use targetcli to create a target,the default type for /srv/iscsi/disk1.img
is var_t,and you can login the created target with iscsiadm;but if you use tgtdadm you will get"invalid request",unless you change the type to tgtd_var_lib_t
root@localhost lnie]# ll -Z /srv/iscsi/disk1.img 
-rw-r--r--. 1 root root unconfined_u:object_r:var_t:s0 419430400 Nov 18 18:20 /srv/iscsi/disk1.img
[root@localhost lnie]# tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2016-09.example.com:test-target
[root@localhost lnie]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /srv/iscsi/disk1.img
tgtadm: invalid request
[root@localhost lnie]# chcon -t tgtd_var_lib_t /srv/iscsi/disk1.img
[root@localhost lnie]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /srv/iscsi/disk1.img
[root@localhost lnie]#
Comment 15 lnie 2016-11-23 04:10:00 UTC 
Created attachment 1222975 [details]
picture3
Comment 16 lnie 2016-11-23 04:23:03 UTC 
Created attachment 1222976 [details]
journal when try to create a target using tgtadm with the default var_t disk type
Comment 17 Radek Vykydal 2016-11-23 08:50:05 UTC 
So it seems you are actually hitting iSCSI server-side issue not related to the installer (described in bug 1396951.

The installer issue I am seeing (comment #12) is already reported by you in bug 1395620. I'll comment there.
Comment 18 lnie 2016-11-28 02:25:24 UTC 
Thanks for your reply.What's about the issue,if it is,I mentioned in comment#14,which team should I assign to?
Comment 19 Radek Vykydal 2016-11-28 08:26:27 UTC 
I think it would be scsi-target-utils,
but according to
https://fedoraproject.org/wiki/Scsi-target-utils_Quickstart_Guide
it seems you are expected to set the proper selinux attributes on the backing device.
Note You need to log in before you can comment on or make changes to this bug.