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