Bug 1594946 - libiscsi.so.0: undefined symbol: iscsi_session_persistent_address_get in iscsi-initiator-utils-
Summary: libiscsi.so.0: undefined symbol: iscsi_session_persistent_address_get in iscs...
Alias: None
Product: Fedora
Classification: Fedora
Component: iscsi-initiator-utils
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Chris Leech
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F29FinalBlocker
TreeView+ depends on / blocked
Reported: 2018-06-25 19:43 UTC by Adam Williamson
Modified: 2018-07-02 18:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-06-30 23:03:41 UTC
Type: Bug

Attachments (Terms of Use)

Description Adam Williamson 2018-06-25 19:43:04 UTC
Since iscsi-initiator-utils- 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:


and that's it. If you do the same on an image from the previous compose, you get the same list, *plus*:


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

Comment 1 Adam Williamson 2018-06-25 20:18:40 UTC
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.

Comment 2 Adam Williamson 2018-06-25 20:36:11 UTC
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)

Comment 3 Adam Williamson 2018-06-25 20:38:16 UTC
Hum, actually, it seems to be a *new* function in the libopeniscsiusr stuff.

Comment 4 Adam Williamson 2018-06-25 20:48:31 UTC
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...

Comment 5 Adam Williamson 2018-06-25 21:02:51 UTC
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).


Comment 6 Adam Williamson 2018-06-25 22:53:17 UTC
Fix confirmed with a modified installer image:


will close with next Rawhide compose.

Comment 7 Gris Ge 2018-06-27 12:18:47 UTC
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.

Comment 8 Adam Williamson 2018-06-27 16:22:10 UTC
Ah, I see. So once that's finished to everyone's satisfaction and things that use libiscsi are ported, libiscsi will go away?

Comment 9 Gris Ge 2018-06-28 05:04:02 UTC
Yes. That's the plan.

Comment 10 Adam Williamson 2018-06-30 23:03:41 UTC
So we're getting Rawhide composes again and the iSCSI test is passing, so we can close this.

Note You need to log in before you can comment on or make changes to this bug.