search for: contains_supermin_appli

...> diff --git a/lib/appliance.c b/lib/appliance.c > index f12918573..06ee06f71 100644 > --- a/lib/appliance.c > +++ b/lib/appliance.c > @@ -137,16 +137,6 @@ build_appliance (guestfs_h *g, > CLEANUP_FREE char *path = NULL; > > /* 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); > - > -...

...pliance.c +++ b/src/appliance.c @@ -48,7 +48,7 @@ static int dir_contains_files (guestfs_h *g, const char *dir, ...); static int contains_old_style_appliance (guestfs_h *g, const char *path, void *data); static int contains_fixed_appliance (guestfs_h *g, const char *path, void *data); static int contains_supermin_appliance (guestfs_h *g, const char *path, void *data); -static int build_supermin_appliance (guestfs_h *g, const char *supermin_path, uid_t uid, char **kernel, char **initrd, char **appliance); +static int build_supermin_appliance (guestfs_h *g, const char *supermin_path, char **kernel, char **initrd, c...

...liance 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); OK, I see, that is i...

...3 insertions(+), 1 deletion(-) > > diff --git a/lib/appliance.c b/lib/appliance.c > index f12918573..5738e4e7f 100644 > --- a/lib/appliance.c > +++ b/lib/appliance.c > @@ -199,7 +199,9 @@ contains_fixed_appliance (guestfs_h *g, const char *path, void *data) > static int > contains_supermin_appliance (guestfs_h *g, const char *path, void *data) > { > - return dir_contains_files (g, path, "supermin.d", NULL); > + return dir_contains_files (g, path, > + "supermin.d/base.tar.gz", > + "supermin.d/...

...rst 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. 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)). (2) If the fixed appliance was located...

On Tue, Apr 07, 2020 at 02:33:20PM +0200, Pino Toscano wrote: > On Tuesday, 7 April 2020 14:18:47 CEST Richard W.M. Jones wrote: > > On Tue, Apr 07, 2020 at 01:25:02PM +0200, Pino Toscano wrote: > > > The important thing is still that that you need to have space for the > > > temporary files somewhere: be it /var/tmp, /mnt/scratch, whatever. > > > Because of

...fers a supermin appliance before a fixed appliance; the whole logic is here: https://github.com/libguestfs/libguestfs/blob/c2c11382bbeb4500f3388a31ffd08cfc18b0de40/lib/appliance.c In particular, see the locate_or_build_appliance function and the comment before it, and contains_fixed_appliance & contains_supermin_appliance helper functions. If you have a setup like: /usr/lib64/guestfs ├── initrd ├── kernel ├── README.fixed ├── root └── supermin.d ├── base.tar.gz └── packages with LIBGUESTFS_PATH=/usr/lib64/guestfs, then the logic fill find first the two files under supermin.d as supermin appliance, and...

..."README.fixed", > - "kernel", "initrd", "root", NULL); > + "kernel", "initrd", "root", (void *) NULL); > } > > static int > @@ -238,7 +238,7 @@ contains_supermin_appliance (guestfs_h *g, const char *path, void *data) > { > return dir_contains_files (g, path, > "supermin.d/base.tar.gz", > - "supermin.d/packages", NULL); > + "supermin.d/...

Hi, this is a prototype of something I've around for some time. Basically it is about adding new appliances in addition to the main one currently used and kept up-to-date automatically: this way it is possible to create new appliances with extra packages, to be used in specific contexts (like virt-rescue, with more network/recovery tools) without filling the main appliance. It's still

This is the libguestfs companion patch to: https://www.redhat.com/archives/libguestfs/2013-September/msg00045.html Rich.

Doing qemu feature detection in the direct backend takes ~100ms because we need to run `qemu -help' and `qemu -devices ?', and each of those interacts with glibc's very slow link loader. Fixing the link loader is really hard. Instead memoize the output of those two commands. This patch series first separates all the code dealing with qemu into a separate module (src/qemu.c) and

Inspired by libvirt's virCommand* internal mini-library, this adds some internal APIs for running commands. The first patch contains the new APIs. The subsequent patches change various parts of the library over to use it. Rich.

Various changes/fixes to use smaller stack frames. Rich.

...uestfs_h *g, const char *dir, const char *file); +static int dir_contains_files (guestfs_h *g, const char *dir, ...); static int contains_old_style_appliance (guestfs_h *g, const char *path, void *data); static int contains_fixed_appliance (guestfs_h *g, const char *path, void *data); static int contains_supermin_appliance (guestfs_h *g, const char *path, void *data); @@ -170,13 +170,13 @@ build_appliance (guestfs_h *g, static int contains_old_style_appliance (guestfs_h *g, const char *path, void *data) { - return dir_contains_files (path, kernel_name, initrd_name, NULL); + return dir_contains_files (g, path...

This preliminary patch series adds a libvirt backend to libguestfs. It's for review only because although it launches the guest OK, there are some missing features that need to be implemented. The meat of the patch is in part 4/4. To save you the trouble of interpreting libxml2 fragments, an example of the generated XML and the corresponding qemu command line are attached below. Note the