Howdy. Is there any intention of supporting libguestfs on non-Fedora targets (given a sufficiently new qemu or kvm)?
As background: I have a bunch of in-house QA infrastructure, which happens to include my own, internally developed tools intended to address the same problems as libguestfs. (One tool, for FUSE-mounting from a guest, used serial ports rather than the vmchannel mechanism, a buildroot/uClibc embedded userland rather than a stripped Fedora, qemu-nbd+nbd-client proxied over serial for getting the block device into the guest, UML rather than qemu or kvm, and a patched ccgfs+FUSE for getting the guest's filesystem back out onto the host).
Libguestfs is clearly more mature and flexible than my personal hackery, so I'm looking at migrating to it -- but right now, I'm having trouble building it for my VM servers' platform, which is effectively RHEL5 with kvm-85 and a modern host kernel. Specific issues follow:
----
futimens() isn't available on glibc 2.5, and do_touch() doesn't presently degrade gracefully to a less-capable call without it:
guestfsd-file.o: In function `do_touch': /home/cduffy/public_git/libguestfs/daemon/file.c:49: undefined reference to `futimens'
----
It was necessary to explicitly set OCAMLC=no OCAMLFIND=no (bypassing build of the ocaml bits) to prevent the build from breaking early, apparently due to C interface changes between the expected OCaml and the ocaml-3.09.3-1.el5 which is present. [TODO: more detail]
----
make-initramfs had numerous complaints: + it expected /var/lib/yum to exist within the initramfs root, which it did not + library versions mismatched between host and guest: libtinfo.so.5 (from ncurses, needed by /bin/sh) isn't available on RHEL5 natively (easily worked around), and the glibc versions don't match (not easily worked around). + unless my PATH included /usr/sbin, builds failed with "/usr/bin/fakechroot: line 107: exec: chroot: not found" + rpm %pre scripts all failed due to the previously mentioned version mismatches.
----
I haven't gotten beyond the last of these issues on account of the glibc mismatch. Before I proceed -- is my goal reasonable, or am I better off sticking with my in-house solution for the time being?
Thanks!
On Sun, May 03, 2009 at 07:05:37PM -0500, Charles Duffy wrote:
Howdy. Is there any intention of supporting libguestfs on non-Fedora targets (given a sufficiently new qemu or kvm)?
First of all, sorry for the delay in answering (I'm currently on holiday). Secondly, thank you for your detailed and specific bug reports.
Many of these things are simply bugs in libguestfs and/or febootstrap. We don't have a bug tracker for libguestfs yet, and so I will add these to the top level 'BUGS' file in the git repo (shortly).
As background: I have a bunch of in-house QA infrastructure, which happens to include my own, internally developed tools intended to address the same problems as libguestfs. (One tool, for FUSE-mounting from a guest, used serial ports rather than the vmchannel mechanism, a buildroot/uClibc embedded userland rather than a stripped Fedora, qemu-nbd+nbd-client proxied over serial for getting the block device into the guest, UML rather than qemu or kvm, and a patched ccgfs+FUSE for getting the guest's filesystem back out onto the host).
Yes, this is certainly an approach that we looked at. The reasons why we chose to not do this are summarised on my blog here:
http://rwmj.wordpress.com/2009/03/20/why-not-use-a-minimal-distribution/
Libguestfs is clearly more mature and flexible than my personal hackery, so I'm looking at migrating to it -- but right now, I'm having trouble building it for my VM servers' platform, which is effectively RHEL5 with kvm-85 and a modern host kernel. Specific issues follow:
futimens() isn't available on glibc 2.5, and do_touch() doesn't presently degrade gracefully to a less-capable call without it:
Yes, this is obviously a bug in libguestfs. Noted.
guestfsd-file.o: In function `do_touch': /home/cduffy/public_git/libguestfs/daemon/file.c:49: undefined reference to `futimens'
It was necessary to explicitly set OCAMLC=no OCAMLFIND=no (bypassing build of the ocaml bits) to prevent the build from breaking early, apparently due to C interface changes between the expected OCaml and the ocaml-3.09.3-1.el5 which is present. [TODO: more detail]
Also a bug in libguestfs. Noted. We shouldn't depend on anything in OCaml 3.10, but since I haven't tested it with any earlier versions, there is some hidden assumption somewhere.
make-initramfs had numerous complaints:
- it expected /var/lib/yum to exist within the initramfs root, which it
did not
A bug in febootstrap. Noted as http://bugzilla.redhat.com/499369
- library versions mismatched between host and guest: libtinfo.so.5
(from ncurses, needed by /bin/sh) isn't available on RHEL5 natively (easily worked around), and the glibc versions don't match (not easily worked around).
The background to this one is that we build an appliance with one Fedora distro (eg. Fedora 10), and we also build on a possibly different platform (eg. CentOS 5). Copying programs built on the host (eg. guestfsd) to the appliance is problematic.
This appears to be a similar, but different problem, with febootstrap / yum. I'm a little confused actually because there shouldn't be a mismatch possible here.
Anyhow, when building libguestfs in Fedora, we avoid any problems by making sure the appliance is built from precisely the same RPMs as the host distribution. So copying guestfsd from the host to the appliance should not present any problem.
When building on CentOS 5.3, I intend that the appliance should also be CentOS 5.3.
- unless my PATH included /usr/sbin, builds failed with
"/usr/bin/fakechroot: line 107: exec: chroot: not found"
I suspect a bug in fakechroot, but I will look into this one in more detail later today.
- rpm %pre scripts all failed due to the previously mentioned version
mismatches.
I haven't gotten beyond the last of these issues on account of the glibc mismatch. Before I proceed -- is my goal reasonable, or am I better off sticking with my in-house solution for the time being?
Well I hope you can use libguestfs of course!
Anyhow, I am currently building, or trying to build, libguestfs and the dependencies for CentOS 5.3 (i386). I will follow up with notes as things proceed.
Thanks again for the bug reports.
Rich.
On Wed, May 06, 2009 at 01:02:16PM +0100, Richard W.M. Jones wrote:
make-initramfs had numerous complaints:
- it expected /var/lib/yum to exist within the initramfs root, which it
did not
A bug in febootstrap. Noted as http://bugzilla.redhat.com/499369
FYI I couldn't reproduce this one. Yum from CentOS 5.3 works fine for me, modulo the other bugs which are now fixed also.
Rich.
Just following up here with my notes on building libguestfs and dependencies on RHEL 5 and derived distributions. In fact this build is being done on a CentOS 5.3 / i386 machine.
----------------------------------------------------------------------
(1) I note that fakeroot and fakechroot in EPEL are ancient history. Therefore pull fakeroot and fakechroot source RPMs from Rawhide, and use those instead.
fakeroot 1.12.2-21 fakechroot 2.9-20
(2) Neither SRPM can be rebuilt directly because of the MD5/SHA change that happened in RPM. Therefore I have to unpack them by hand using `rpm2cpio'.
(3) fakeroot builds with no problem.
(4) fakechroot requires a small patch to autogen.sh in order to build on CentOS [attached].
After building, all binary RPMs are installed.
(5) Build febootstrap from git repo.
(6) Test febootstrap:
./febootstrap fedora-10 f10
Many scriptlets fail because of a glibc version problem. I don't understand why it's using the host glibc and not the appliance / fakechrooted glibc, so this may be a bug in fakechroot or a problem with fakechroot on this older glibc.
./febootstrap centos-5 c5 http://mirror.centos.org/centos-5/5.3/os/i386/
[More to come in a followup posting]
On Wed, May 06, 2009 at 01:40:12PM +0100, Richard W.M. Jones wrote:
./febootstrap centos-5 c5 http://mirror.centos.org/centos-5/5.3/os/i386/
This works perfectly. Barring the known problems with the version of fakechroot being used, such as error "/etc/ld.so.cache~: Permission denied" which are all non-fatal.
(7) Size of centos-5 @Core febootstrapped installation:
$ du -sh c5 414M c5
(8) Proceed to building libguestfs. I had to install a few dependencies such as OCaml, java-devel, ruby-devel, perl-devel, python-devel, etc.
(9) Build libguestfs from git repo. Since I haven't installed febootstrap, I need to adjust the PATH to use my compiled-but-not- installed version. Also disable the qemu vmchannel test since we'll be using a custom-built qemu later. We also have to set the appliance parameters so that we end up with a CentOS 5.3-derived appliance.
PATH=../febootstrap:$PATH \ vmchannel_test=no \ ./autogen.sh \ --with-repo=centos-5 \ --with-mirror=http://mirror.centos.org/centos-5/5.3/os/i386/ \ --with-updates=none
[More to follow ...]
On Wed, May 06, 2009 at 02:32:33PM +0100, Richard W.M. Jones wrote:
PATH=../febootstrap:$PATH \ vmchannel_test=no \ ./autogen.sh \ --with-repo=centos-5 \ --with-mirror=http://mirror.centos.org/centos-5/5.3/os/i386/ \ --with-updates=none
(10) Forgot about the Perl modules, more OCaml stuff, rake and Augeas, so I install those from EPEL (perl-Test-Pod, perl-Test-Pod-Coverage, augeas-devel, rubygem-rake, ocaml-ocamldoc, ocaml-findlib-devel)
perl-Sys-Virt isn't available in CentOS or EPEL. Yet. It will be in RHEL 5.4. For now we won't be able to build virt-inspector.
(11) Try the above configure command again ... it works.
(12) Notice that there's a bug in the configure script which means that even though there are Perl modules missing which are needed for virt-inspector, it still configures that component. Bug noted.
[More to follow]
(13) make
(14) Warning about -fstrict-aliasing in guestfs_get_default_main_loop.
I'm certain this can be ignored.
(15) Lots of warnings about -fstrict-aliasing in rpcgen-generated code.
Ignore these for now. We had the same errors in libvirt for a long time with no apparent effect on code generation.
(16) Missing futimens function in do_touch (previously reported bug).
Fixed.
(17) fish.c: Implicit declaration of `isspace'.
Fixed.
(18) In OCaml bindings, implicit declaration of `CAMLreturnT'.
Fixed.
(19) In Ruby bindings, implicit declaration of `RARRAY_LEN'.
Fixed.
[More to come ...]
On Wed, May 06, 2009 at 03:28:36PM +0100, Richard W.M. Jones wrote:
(13) make
(20) Get the PATH right so we pick up febootstrap:
PATH=../febootstrap:$PATH make
(21) "No package augeas-libs available".
/me grumbles about package name changes.
You have to change `-i augeas-libs' to `-i augeas' in make-initramfs.sh and make-initramfs.sh.in. Unfortunately this change is only applicable to RHEL 5, and cannot be made in libguestfs upstream. [See attached patch]
(22) "exec: chroot not found"
To workaround this temporarily I do:
PATH=../febootstrap:/usr/sbin:$PATH make
[That is building away now, more to follow]
(23) Unfortunately there's no augeas at all in CentOS 5.3 base distribution. We should really make support for Augeas completely optional, since a lot of the time those aug_* commands won't be needed by end users.
I don't have the stomach to make this change right now, since I'm doing this on a green-screen terminal without even copy and paste never mind such luxuries as the "WorldWideWeb" ...
I hacked around this for now, but noted the problem in the TODO file.
[More to follow]
[Continuing to build ...]
(24) febootstrap-minimize program is not removing locale files, which made the appliance image about 75MB larger than it needed to be.
Small patch added to git repo to fix this.
(25) Meanwhile, building a custom qemu from upstream qemu git. I am using the attached wrapper script, and I will invoke libguestfs programs first setting this environment variable:
LIBGUESTFS_QEMU=/path/to/qemu.wrapper
including running the testsuite like this:
LIBGUESTFS_QEMU=/path/to/qemu.wrapper make check
and guestfish w/o installing like this:
LIBGUESTFS_QEMU=/path/to/qemu.wrapper ./fish/guestfish
[More to follow ...]
I'm just uploading RPMs of libguestfs that I built for RHEL 5.3 i386 (actually CentOS 5.3 + EPEL). You will be able to get them here:
http://et.redhat.com/~rjones/libguestfs/files/RHEL-5
in around 60 minutes time.
You absolutely must read the README file and follow the instructions there.
There are four issues which I know about at the moment, and probably a few others. The package does however pass all of the C API tests, which is generally a good sign. The issues are:
(1) On RHEL 5, IDE devices are called '/dev/hd*', whereas on Fedora 11, IDE devices are called '/dev/sd*'. This means that any call which takes or returns a device name, and there are many such calls, must use the /dev/hd* form, eg.
guestfs_list_partitions (g); ==> [ "/dev/hda1", "/dev/hda2" ]
guestfs_pvcreate (g, "/dev/hda1");
This is annoying if you are writing scripts that must work on both versions of RHEL (5 & 6). You have to first call guestfs_- list_devices, and from that you can tell the format of devices names that the current version uses. If you look in the main() function of 'tests.c' in the source, you can see some code which does this, so that the tests can run using both formats.
(2) RHEL 5 didn't support FUSE or NTFS-3g. So unfortunately you may not be able to read Windows (NTFS) partitions. This is a matter of backporting the relevant code to EPEL. I haven't yet worked out how hard that is going to be. (Note there may be other ways around this, such as using the in-kernel NTFS device driver).
(3) You need to compile your own recent qemu and provide a qemu wrapper for it. See the README for more details.
(4) There is no Augeas support in this version. (Bug in febootstrap).
Rich.
Richard,
Thank you kindly for going above and beyond on this one!
I've tried rebuilding these packages on an x86_64 host; the process goes smoothly until febootstrap attempts to install the RPMs within the initramfs, at which point things start to go awry; it smells like we're trying to LD_PRELOAD the x86_64-native fakechroot libraries into 32-bit processes running in the guest environment being created.
Tweaking the spec file to pull packages for %{_arch}, rather than i386 unconditionally, works around this, but eventually fails during the test phase -- as I had augeas installed on my host (from the EPEL packages), and the guest didn't have those libraries pulled in:
guestfsd: error while loading shared libraries: libaugeas.so.0: cannot open shared object file: No such file or directory Kernel panic - not syncing: Attempted to kill init!
This was trivial to work around by uninstalling augeas from the host before rebuilding; it did, however, expose that the qemu instance never exits when a panic occurs when running under the test suite. Perhaps "panic=1" should be passed as a kernel parameter to the guest to trigger a reboot on panic, coupled with -no-reboot to ensure that qemu exits?
After this point, the only remaining issue is that the ocaml bindings aren't being built, resulting in a packaging failure:
RPM build errors: File not found: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.a File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.cmxa File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.cmx File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.mli File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/stublibs/*.so File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/stublibs/*.so.owner File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.a File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.cmxa File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.cmx File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.mli
I'll look into this one tomorrow.
Thanks again!
Charles Duffy wrote:
After this point, the only remaining issue is that the ocaml bindings aren't being built, resulting in a packaging failure:
RPM build errors: File not found: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.a [...]
As it turns out, the issue was not that the ocaml bindings aren't being built, but that they were being installed under /usr/lib/ocaml as opposed to /usr/lib64/ocaml.
On Thu, May 07, 2009 at 08:18:26PM -0500, Charles Duffy wrote:
Charles Duffy wrote:
After this point, the only remaining issue is that the ocaml bindings aren't being built, resulting in a packaging failure:
RPM build errors: File not found: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.a [...]
As it turns out, the issue was not that the ocaml bindings aren't being built, but that they were being installed under /usr/lib/ocaml as opposed to /usr/lib64/ocaml.
Strange one - this works for me on Fedora x86_64 ..
I'll look into this a bit more when I come to add libguestfs to EPEL.
Rich.
Richard W.M. Jones wrote:
On Thu, May 07, 2009 at 08:18:26PM -0500, Charles Duffy wrote:
Charles Duffy wrote:
After this point, the only remaining issue is that the ocaml bindings aren't being built, resulting in a packaging failure:
RPM build errors: File not found: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.a [...]
As it turns out, the issue was not that the ocaml bindings aren't being built, but that they were being installed under /usr/lib/ocaml as opposed to /usr/lib64/ocaml.
Strange one - this works for me on Fedora x86_64 ..
I'll look into this a bit more when I come to add libguestfs to EPEL.
You were indicating that you were having trouble reproducing this issue? It's easy enough to work around (s@%{_libdir}@/usr/lib*@), but I'm still seeing this:
error: Installed (but unpackaged) file(s) found: /usr/lib/ocaml/guestfs/META /usr/lib/ocaml/guestfs/guestfs.cmi /usr/lib/ocaml/guestfs/guestfs.cmx /usr/lib/ocaml/guestfs/guestfs.mli /usr/lib/ocaml/guestfs/libmlguestfs.a /usr/lib/ocaml/guestfs/mlguestfs.a /usr/lib/ocaml/guestfs/mlguestfs.cma /usr/lib/ocaml/guestfs/mlguestfs.cmxa /usr/lib/ocaml/stublibs/dllmlguestfs.so /usr/lib/ocaml/stublibs/dllmlguestfs.so.owner
RPM build errors: File not found: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs/*.a File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs/*.cmxa File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs/*.cmx File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs/*.mli File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/stublibs/*.so File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/stublibs/*.so.owner File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs/*.a File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs/*.cmxa File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs/*.cmx File not found by glob: /var/tmp/libguestfs-1.0.34-1.3-root/usr/lib64/ocaml/guestfs/*.mli Installed (but unpackaged) file(s) found: /usr/lib/ocaml/guestfs/META /usr/lib/ocaml/guestfs/guestfs.cmi /usr/lib/ocaml/guestfs/guestfs.cmx /usr/lib/ocaml/guestfs/guestfs.mli /usr/lib/ocaml/guestfs/libmlguestfs.a /usr/lib/ocaml/guestfs/mlguestfs.a /usr/lib/ocaml/guestfs/mlguestfs.cma /usr/lib/ocaml/guestfs/mlguestfs.cmxa /usr/lib/ocaml/stublibs/dllmlguestfs.so /usr/lib/ocaml/stublibs/dllmlguestfs.so.owner
On Wed, May 27, 2009 at 04:23:35PM -0500, Charles Duffy wrote:
Richard W.M. Jones wrote:
On Thu, May 07, 2009 at 08:18:26PM -0500, Charles Duffy wrote:
Charles Duffy wrote: As it turns out, the issue was not that the ocaml bindings aren't being built, but that they were being installed under /usr/lib/ocaml as opposed to /usr/lib64/ocaml.
Strange one - this works for me on Fedora x86_64 ..
I'll look into this a bit more when I come to add libguestfs to EPEL.
You were indicating that you were having trouble reproducing this issue? It's easy enough to work around (s@%{_libdir}@/usr/lib*@), but I'm still seeing this:
error: Installed (but unpackaged) file(s) found: /usr/lib/ocaml/guestfs/META /usr/lib/ocaml/guestfs/guestfs.cmi /usr/lib/ocaml/guestfs/guestfs.cmx /usr/lib/ocaml/guestfs/guestfs.mli /usr/lib/ocaml/guestfs/libmlguestfs.a /usr/lib/ocaml/guestfs/mlguestfs.a /usr/lib/ocaml/guestfs/mlguestfs.cma /usr/lib/ocaml/guestfs/mlguestfs.cmxa /usr/lib/ocaml/stublibs/dllmlguestfs.so /usr/lib/ocaml/stublibs/dllmlguestfs.so.owner
That's the correct location on 32 bit archs. What's the ocamlfind install command that it actually runs? Are you passing --libdir=%{_libdir} to the configure? Note that I've built this successfully on the EL-5 builders on both i386 and x86_64 so it should just work.
Rich.
On Thu, May 07, 2009 at 07:58:56PM -0500, Charles Duffy wrote:
Richard,
Thank you kindly for going above and beyond on this one!
I've tried rebuilding these packages on an x86_64 host; the process goes smoothly until febootstrap attempts to install the RPMs within the initramfs, at which point things start to go awry; it smells like we're trying to LD_PRELOAD the x86_64-native fakechroot libraries into 32-bit processes running in the guest environment being created.
Tweaking the spec file to pull packages for %{_arch}, rather than i386 unconditionally, works around this, but eventually fails during the test phase -- as I had augeas installed on my host (from the EPEL packages), and the guest didn't have those libraries pulled in:
Right - the appliance has to have the same architecture as the host, so that is indeed a sensible change to make.
guestfsd: error while loading shared libraries: libaugeas.so.0: cannot open shared object file: No such file or directory Kernel panic - not syncing: Attempted to kill init!
Yes - this is really a bug in febootstrap. It should be possible to pass several repositories to febootstrap, so that we can pass CentOS + EPEL + updates. This isn't possible with febootstrap at the moment, and because CentOS doesn't contain Augeas, we end up with the situation that you described of Augeas being found on the host but not on the appliance. The workaround you used is the same as the one I used.
This was trivial to work around by uninstalling augeas from the host before rebuilding; it did, however, expose that the qemu instance never exits when a panic occurs when running under the test suite. Perhaps "panic=1" should be passed as a kernel parameter to the guest to trigger a reboot on panic, coupled with -no-reboot to ensure that qemu exits?
An excellent suggestion, thanks. I have added it to the git repo.
After this point, the only remaining issue is that the ocaml bindings aren't being built, resulting in a packaging failure:
RPM build errors: File not found: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.a File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.cmxa File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.cmx File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.mli File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/stublibs/*.so File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/stublibs/*.so.owner File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.a File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.cmxa File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.cmx File not found by glob: /var/tmp/libguestfs-1.0.19-1-root/usr/lib64/ocaml/guestfs/*.mli
I'll look into this one tomorrow.
This might be a missing dep. The ones needed for OCaml are, I think,
ocaml ocaml-findlib-devel ocaml-ocamldoc
I have checked and it does work with OCaml 3.09.3 from EPEL now (after I fixed the bug that you raised earlier).
Rich.
-
Charles Duffy -
Richard W.M. Jones