Arch Linux

I just checked the current package, it is linked to libiscsi.so.4, not libiscsi.so.1. You can verify this with `objdump -p /usr/bin/qemu-img | grep iscsi`. This means there is probably something else on your system trying to load the old lib. Take a look at your AUR packages.

please run :

ldd /usr/bin/qemu-img

the correct output of this command is :

linux-vdso.so.1 (0x00007fffc4c4d000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f57e6425000)
libaio.so.1 => /usr/lib/libaio.so.1 (0x00007f57e6223000)
libiscsi.so.4 => /usr/lib/libiscsi.so.4 (0x00007f57e5fff000)
libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007f57e5d8b000)
libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007f57e5b62000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f57e5854000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f57e564c000)
libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007f57e5447000)
libgnutls.so.28 => /usr/lib/libgnutls.so.28 (0x00007f57e5124000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57e4f08000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f57e4c03000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57e49ed000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f57e464a000)
libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007f57e4369000)
libidn.so.11 => /usr/lib/libidn.so.11 (0x00007f57e4135000)
libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f57e3ec5000)
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f57e3ab3000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007f57e3866000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007f57e3581000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007f57e334f000)
libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007f57e314b000)
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f57e2edc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f57e663b000)
libp11-kit.so.0 => /usr/lib/libp11-kit.so.0 (0x00007f57e2c76000)
libtasn1.so.6 => /usr/lib/libtasn1.so.6 (0x00007f57e2a63000)
libnettle.so.4 => /usr/lib/libnettle.so.4 (0x00007f57e2835000)
libhogweed.so.2 => /usr/lib/libhogweed.so.2 (0x00007f57e2606000)
libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f57e238f000)
libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f57e217d000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f57e1f79000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007f57e1d6c000)
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007f57e1b68000)
libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f57e1950000)
libffi.so.6 => /usr/lib/libffi.so.6 (0x00007f57e1747000)

No, please do not run ldd. ldd is recursive so it won't really help us here.

ping vmaffione, any response?

Sorry for the late response.

My `objdump -p /usr/bin/qemu-img | grep iscsi` output seems good:
NEEDED libiscsi.so.4

However, the problem is still there. What should I do?

These are my AUR packages:

adduser 1.15-5
cloog 0.18.1-3
fspcc 1.7-1
isl 0.13-1
mininet 2.1.0p1-1
netmap 3.18-1
xen 4.4.1-3

I tried objdump on these, but I don't see conflicts w.r.t. libiscsi.

Actually, xen uses qemu, but checking this

$ A=$(pacman -Ql xen | cut -d' ' -f 2)
$ for a in $A; do objdump -p $a 2> /dev/null | grep scsi; done

I only got this
NEEDED libiscsi.so.4
NEEDED libiscsi.so.4
NEEDED libiscsi.so.4
NEEDED libiscsi.so.4
NEEDED libiscsi.so.4

That seems to be ok.

I guess the first thing would be to make sure you're actually running qemu-img from the package, try `which qemu-img`.

After that, you can try lddtree from the pax-utils package.

Ahh, found it (thanks strace).

qemu official package installs binaries in /usr/bin, but for some reason I don't know I still have other qemu old binaries in /usr/local/bin, so that when running

$ qemu-img

bash was actually finding /usr/local/bin/qemu-img instead of /usr/bin/qemu-img.
And, of course, /usr/local/bin/qemu-img is linked agains libiscsi.so.1.

No idea why I have these old binaries - but could be my fault (e.g. 'make install' manual installation, even if I don't remember having done that).

Sorry didn't see your last comment. You were right.