[fedora-virt] Re: libguestfs RPMs for RHEL 5.3

[Richard W.M. Jones]

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.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora