On 25.04.2017 18:33, Richard W.M. Jones wrote:
On Tue, Apr 25, 2017 at 06:13:37PM +0300, Pavel Butsykin wrote:
On 25.04.2017 16:04, Richard W.M. Jones wrote:
Can you see what:
guestfish get-path
/usr/lib64/guestfs
prints? Are you setting LIBGUESTFS_PATH at all?
No.
# ls /usr/lib64/guestfs initrd kernel README.fixed root supermin.d
libguestfs by default uses a single path to search fixed appliance and supermin.d. It seemed to me that the presence of options "--disable appliance --disable-daemon" must exclude the use of build_supermin_appliance. But libguestfs in any case trying to find supermin.d.
OK, I see - what's actually happening is that you've got a path which is both a fixed appliance and a supermin appliance (although maybe it only appears to be a supermin appliance -- libguestfs just looks for the "supermin.d" entry and decides it's a supermin appliance).
Maybe it's not quite right to make such decisions based on the contents of the directory.
Yes that's right, but see below.
Moreover, we have a situation with undefined behavior. if we only use the fixed appliance, then we can't rely on the contents of directories, because there are many ways to stumble on supermin.d
Also, I still don't understand what the priority of the search appliances was supposed to actually use. Because in the documentation the first step is to search for fixed appliance, but is actually supermin.d(for building appliance).
There's not a priority in this situation. It wasn't intended that two different appliances would be on the exact same path.
As I see using the same path for different appliances is not a problem. Because build_appliance() first looks for the supermin.d in the g->path, and then the fixed appliance in the same g->path. Therefore, setting the two paths into LIBGUESTFS_PATH=/lib64/guestfs/appliance2: /lib64/guestfs doesn't help.
Some possible solutions:
(1) Make the check in lib/appliance.c: contains_supermin_appliance more robust.
It could perhaps be changed so that it checks that at least "base.tar.gz" and "packages" are found within the supermin.d directory. Those are the minimum two files that must be in a supermin appliance (see supermin(8)).
Empty supermin.d is not a problem in this situation, supermin.d with content may belong to a different libguestfs version or come from arbitrary utilities/packages.
(2) If the fixed appliance was located somewhere else, you could do:
LIBGUESTFS_PATH=/path/to/somewhere/else:/usr/lib64/guestfs export LIBGUESTFS_PATH
and then it would look for the fixed appliance in /path/to/somewhere/else and use it. If the fixed appliance exists there, then it would never check /usr/lib64/guestfs.
It's a bit wrong, the first step is search supermin.d in all specified directories: /* Step (1). */ r = find_path (g, contains_supermin_appliance, NULL, &supermin_path); if (r == -1) return -1; if (r == 1) /* Step (2): build supermin appliance. */ return build_supermin_appliance (g, supermin_path, kernel, initrd, appliance); ... So, supermin.d will be found in /usr/lib64/guestfs and the search for the fixed applaince will not even. Here find_path() searches for all paths in g->path.
(3) You could also compile a different path into libguestfs.
Unfortunately there's no way to specify it at configure time, but see GUESTFS_DEFAULT_PATH in the sources.
(4) Delete /usr/lib64/guestfs/supermin.d
It can even be dangerous, because supermin.d may belong to any packages or utilities. I propose to consider a patch that adds some certainty of behaviour in the work with appliances, and solves the above notation issue. What do you think? (see path in the next message)
Rich.