Bug 1396935

Created attachment 1222322 [details]
picture2

Created attachment 1222323 [details]
screenshot of the issue

Created attachment 1222324 [details]
anaconda.log

Created attachment 1222326 [details]
packaging.log

Created attachment 1222328 [details]
program.log

Created attachment 1222329 [details]
storage.log

Created attachment 1222330 [details]
syslog

Created attachment 1222331 [details]
x.log

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.

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.

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.

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.

(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.

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]#

Created attachment 1222975 [details]
picture3

Created attachment 1222976 [details]
journal when try to create a target using tgtadm with the default var_t disk type

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.

Thanks for your reply.What's about the issue,if it is,I mentioned in comment#14,which team should I assign to?

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.