[Libguestfs] libguestfs-test-tool error, libcap.so - no such file

[Richard W.M. Jones]

On Wed, Jan 16, 2013 at 04:12:21PM -0500, Skippy VonDrake wrote:
> Did install from source of libguestfs-1.20.1 on Ubuntu-12.10.
> And libguestfs-test-tool complains about not finding libcap.so.2
> 
> uptime: 2.26 1.00
> guestfsd: error while loading shared libraries: libcap.so.2: cannot
> open shared object file: No such file or directory
> [    2.277795] Unregister pv shared memory for cpu 0
> [    2.278324] kvm: exiting hardware virtualization
> [    2.278763] sd 2:0:1:0: [sdb] Synchronizing SCSI cache
> [    2.284494] sd 2:0:0:0: [sda] Synchronizing SCSI cache
> [    4.224797] Disabling non-boot CPUs ...
> [    4.225182] Restarting system.
> [    4.225467] machine restart
> 
> Full output at: http://pastebin.com/csndiF2A
> 
> $  sudo find / -name 'libcap.so*' | xargs ls -lh
> /lib/i386-linux-gnu/libcap.so.2 -> libcap.so.2.22
> /lib/i386-linux-gnu/libcap.so.2.22
> /lib/x86_64-linux-gnu/libcap.so -> libcap.so.2
> /lib/x86_64-linux-gnu/libcap.so.2 -> libcap.so.2.22
> /lib/x86_64-linux-gnu/libcap.so.2.22
> 
> Rich, I know that you've stated in the past that you don't do 'install' and
> refer to the run scripts and the README file in response to problems
> installing libguestfs on Ubuntu.
> 
> Should an install of libguestfs be considered as a "do at your own
> risk" endeavor?
> Putting it in the quasi-support realm?

It should work, but it's not necessary, and it may have bad effects.
It will pollute your filesystem with files which are not managed by
dpkg (making them effectively impossible to remove).  It will likely
conflict in strange ways with the real libguestfs dpkg.

The easier way is just to use the ./run script in the libguestfs
directory, eg:

  ./run ./fish/guestfish [etc]

Note that 'make quickcheck', 'make check' etc implicitly uses the
./run script.

> And is the appliance trying to find libcap.so on the host or within
> the appliance when it fails?

The problem above is that libcap.so.2 isn't being copied into the
appliance.  There could be several reasons for this:

(1) Most likely, what is installed on your host doesn't match what is
listed in /etc/apt/sources.list; eg. libcap might have recently had an
soname bump in Ubuntu and you haven't yet installed the new version on
the host (but febootstrap picked up the new version for the
appliance).  Just doing an 'apt-get dist-upgrade' should fix it.

(2) You're mixing the appliance from another installed libguestfs with
the appliance from the libguestfs you built locally.  This doesn't
appear to be the case, from the full output you gave.

(3) Did ./configure pick up that libcap is installed?  Did it link
guestfsd with -lcap?  Did you then uninstall libcap on the host?  Did
febootstrap download libcap during the build?

(4) There's some problem with the dpkg metadata.

(5) There's some bug in febootstrap or the dpkg/apt utilities that it
depends on.

#4 and #5 can be diagnosed by carefully looking at whatever is being
generated in '/usr/local/lib/guestfs/supermin.d/hostfiles', while at
the same time reading this:

  http://libguestfs.org/febootstrap.8.html#supermin_appliances

You can also avoid building the appliance at all by using the fixed
appliance:

  http://libguestfs.org/download/binaries/appliance/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/