[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