Since iscsi-initiator-utils-6.2.0.876-1.git4ef9261.fc29 landed in Fedora-Rawhide-20180620.n.0, the button to add an iSCSI target as an advanced storage device in anaconda has entirely disappeared. After digging through blivet code a bit, I figured out this appears to be because the org.freedesktop.UDisks2.Manager.ISCSI.Initiator dbus interface is just...not there any more. anaconda destroys the button `if not blivet.iscsi.available`. blivet.iscsi.available is a property which seems to just return False, but it's actually wrapped via a decorator `storaged_iscsi_required`, which is really `iSCSIDependencyGuard`. I basically reproduced what iSCSIDependencyGuard does manually in an installer image, and it fails at this point: return safe_dbus.check_object_available(STORAGED_SERVICE, STORAGED_MANAGER_PATH, INITIATOR_IFACE) that returns False. So I dug a bit deeper and looked at what 'check_object_available' does, and found the thing *it* does which fails, which is basically this: intro_data = call_sync("org.freedesktop.UDisks2", "/org/freedesktop/UDisks2/Manager", "org.freedesktop.DBus.Introspectable", "Introspect", None) node_info = Gio.DBusNodeInfo.new_for_xml(intro_data[0]) return any(intface.name == "org.freedesktop.UDisks2.Manager.ISCSI.Initiator" for intface in node_info.interfaces) in other words, it's really just checking the interfaces available on the "org.freedesktop.UDisks2" service and expecting "org.freedesktop.UDisks2.Manager.ISCSI.Initiator" to be among them. But it just isn't. If you just print the list of available interfaces, you get this: org.freedesktop.DBus.Properties org.freedesktop.DBus.Introspectable org.freedesktop.DBus.Peer org.freedesktop.UDisks2.Manager and that's it. If you do the same on an image from the previous compose, you get the same list, *plus*: org.freedesktop.UDisks2.Manager.ISCSI.Initiator at the bottom, and of course the button is present in the installer interface. As this changed in the Fedora-Rawhide-20180620.n.0 compose, and iscsi-initiator-utils-6.2.0.876-1.git4ef9261.fc29 arrived exactly in that compose, it's the obvious suspect as the cause here. Nominating as an F29 Final blocker, as this violates https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria#Network_attached_storage - "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
Aha, I think I see the problem, in the udisks2 systemd service log: Module loading failed: /lib64/libiscsi.so.0: undefined symbol: iscsi_session_persistent_address_get looking into that now.
So...I think the problem is that iscsi_session_persistent_address_get has been split into this new libopeniscsiusr library, but libiscsi itself is not linked against that library: [adamw@adam open-iscsi (master)]$ ldd /usr/lib64/libiscsi.so.0 linux-vdso.so.1 (0x00007fffc6565000) libkmod.so.2 => /lib64/libkmod.so.2 (0x00007f741ab73000) libc.so.6 => /lib64/libc.so.6 (0x00007f741a7b3000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f741a58c000) libz.so.1 => /lib64/libz.so.1 (0x00007f741a375000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f741a15d000) /lib64/ld-linux-x86-64.so.2 (0x00007f741afe5000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7419f3f000)
Hum, actually, it seems to be a *new* function in the libopeniscsiusr stuff.
Wow, this is a weird package - this whole libiscsi is actually patched into the Fedora package with a giant patch (0009-libiscsi.patch) and doesn't exist upstream. Crazy. Trying out a build with the Makefile for libiscsi patched to include -L$(TOPDIR)/libopeniscsiusr -lopeniscsiusr when building the library now...
Yeah, seems like that fixes it. I'm sending a -3 build with that changed now (and will send a -4 build to the f29-python tag, since -2 was the python 3.7 rebuild and -3 will be built back against python 3.6). https://koji.fedoraproject.org/koji/taskinfo?taskID=27864352
Fix confirmed with a modified installer image: https://openqa.stg.fedoraproject.org/tests/321010 will close with next Rawhide compose.
Hi Adam, Thanks for the great work. Upstream refused to include the giant libiscsi.so patch, so I am slowly working on the new upstreamed C API -- libopeniscsiusr. FYI.
Ah, I see. So once that's finished to everyone's satisfaction and things that use libiscsi are ported, libiscsi will go away?
Yes. That's the plan.
So we're getting Rawhide composes again and the iSCSI test is passing, so we can close this.