[Libguestfs] [PATCH] appliance: reorder the steps to search for appliance

Richard W.M. Jones rjones at redhat.com
Tue Apr 25 13:04:51 UTC 2017


On Tue, Apr 25, 2017 at 03:58:45PM +0300, Pavel Butsykin wrote:
> On 25.04.2017 15:11, Richard W.M. Jones wrote:
> >On Tue, Apr 25, 2017 at 02:35:26PM +0300, Pavel Butsykin wrote:
> >>The patch changes the order of the steps to search for fixed/supermin
> >>appliance in accordance with documentation:
> >>
> >>"If the fixed appliance is found, libguestfs skips supermin entirely
> >>  and just runs qemu with the kernel, initrd and root disk from the
> >>  fixed appliance."
> >
> >Does anyone rely on the path-like behaviour of LIBGUESTFS_PATH?  It
> >was a mistake to allow that originally, but we're stuck with it now
> >unfortunately.
> 
> Sorry, but I don't understand what you mean. What is
> "path-like behaviour"? What is the mistake ? The mistake is to use the
> location of supermin.d directory for the decision on build appliance.?

I mean, the mistake was that I allowed search paths in
LIBGUESTFS_PATH, ie.

  LIBGUESTFS_PATH=/a:/b

(rather than just forcing it to be a single path).

> I was faced with the problem that if in appliance directory there is
> supermin.d then libguestfs is trying to build appliance. Even if
> supermin.d is empty, even if libguestfs was built with options
> --disable-appliance --disable-daemon. But as it turned out, the
> behaviour build_appliance() is contrary to the documentation.

Can you see what:

  guestfish get-path

prints?  Are you setting LIBGUESTFS_PATH at all?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW




More information about the Libguestfs mailing list