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