similar to: [PATCH v3] Improve fixed appliance documentation

Move the "FIXED APPLIANCE" section from libguestfs-make-fixed-appliance(1) to the general guestfs(3), so it's more visible and less hidden in the documentation of a rarely-used tool. Expand the FAQ question about libguestfs without supermin, mentioning the build options needed and pointing to the aforementioned new section. --- appliance/libguestfs-make-fixed-appliance.pod | 28

Move the "FIXED APPLIANCE" section from libguestfs-make-fixed-appliance(1) to the general guestfs(3), so it's more visible and less hidden in the documentation of a rarely-used tool. Expand the FAQ question about libguestfs without supermin, mentioning the build options needed and pointing to the aforementioned new section. --- appliance/libguestfs-make-fixed-appliance.pod | 28

On Monday 15 June 2015 15:47:31 Richard W.M. Jones wrote: > On Wed, Jun 10, 2015 at 06:47:44PM +0200, Pino Toscano wrote: > > index e2ee1b5..eebab53 100644 > > --- a/src/guestfs.pod > > +++ b/src/guestfs.pod > > @@ -3540,6 +3540,30 @@ Finally, the child process sends asynchronous messages back to the > > main program, such as kernel log messages. You can register

On Wed, Jun 10, 2015 at 06:47:44PM +0200, Pino Toscano wrote: > index e2ee1b5..eebab53 100644 > --- a/src/guestfs.pod > +++ b/src/guestfs.pod > @@ -3540,6 +3540,30 @@ Finally, the child process sends asynchronous messages back to the > main program, such as kernel log messages. You can register a > callback to receive these messages. > > +=head1 FIXED APPLIANCE > +

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 > >

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,

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

On Thu, Apr 27, 2017 at 03:54:44PM +0300, Pavel Butsykin wrote: [...] > >(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

On Fri, Apr 28, 2017 at 05:03:58PM +0300, Pavel Butsykin wrote: > On 27.04.2017 18:28, Richard W.M. Jones wrote: > > > >On Thu, Apr 27, 2017 at 03:55:10PM +0300, Pavel Butsykin wrote: > >>The flag determines the behavior of working with the appliance, and specifically > >>the choice to use the build supermin appliance or the fixed appliance. If the >

thanks for your reply, When I set the debug mode and run "libguestfs-test-tool" the result is: virtTest@06MYRC5:~$ libguestfs-test-tool ************************************************************ * IMPORTANT NOTICE * * When reporting bugs, include the COMPLETE, UNEDITED * output below in your bug report. * ************************************************************

I download libguestfs from github and fetch to the *origin master*. I tried to build libguestfs in my own linux distro and I followd the http://libguestfs.org/guestfs-building.1.html#using-a-prebuilt-binary-appliance to replace with supermin I download the appliance-1.30.1.tar.xz and appliance-1.30.1.tar.xz.sig and extract the tarball to /home/user/appliance and export

On Tuesday, 7 April 2020 14:59:11 CEST Tomáš Golembiovský wrote: > 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 > > > >

On Fri, Jul 28, 2017 at 11:34:38PM +0800, lampahome wrote: > > guestfish > > add --rw disk.qcow2 > > run > > error: libguestfs: error: cannot find any suitable libguestfs supermin, > > fixed or old-style appliance on LIBGUESTFS_PATH > > > But I echo $LIBGUESTFS_PATH, it's */home/user/appliance* > > I don't know how come going wrong You

On Tuesday 11 November 2014 19:08:58 Mathieu Bouillaguet wrote: > Le 11 nov. 2014 19:03, "Pino Toscano" <ptoscano@redhat.com> a écrit : > > Hi, > > > > (please do not top-reply...) > > > > On Tuesday 11 November 2014 18:32:10 Mathieu Bouillaguet wrote: > > > What I was suggesting, is to let the user manage depencies > > >

Sorry for the top posting, it's the gmail app behavior. It didn't mention the other aspects because they are not a problem. The only "problem" is the package depency. Cordially Le 11 nov. 2014 19:03, "Pino Toscano" <ptoscano@redhat.com> a écrit : > > Hi, > > (please do not top-reply...) > > On Tuesday 11 November 2014 18:32:10 Mathieu

Set LIBGUESTFS_PATH to the default value compiled into and output a warning to STDERR, instead. The previous behavior caused the build to abort when trying to build the sysprep documentation -- without much of a hint of what went wrong. When LIBGUESTFS_PATH was not set, test-events.sh would fail. --- run.in | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/run.in

Hi, (please do not top-reply...) On Tuesday 11 November 2014 18:32:10 Mathieu Bouillaguet wrote: > What I was suggesting, is to let the user manage depencies himself. > > This is what slackware users are used to do anyway. > > It means that we should be able to provide an exhaustive list of > needed packages on the command line. > > As the semantic differ from the

Rich, this wasn't operational. First of all, the image on my version of RHEV-H is kept in other directory. So I did that: 1. $ export FEBOOTSTRAP_KERNEL=/dev/.initramfs/live/vmlinuz0 2. $ echo $FEBOOTSTRAP_KERNEL /dev/.initramfs/live/vmlinuz0 3. $ libguestfs-test-tool ************************************************************ *

Am Freitag, den 22.11.2013, 11:40 +0000 schrieb Исаев Виталий Анатольевич: > Unfortunately, placing the link into the /boot does not work. > libguestfs-test-tool failes with the same message: Could you provide $ ls /boot $ ls /dev/.initramfs/live/ $ ls /dev/.initramfs/live/isolinux/ I just realized that I provided the wrong path, it should be: $ ln -s

Rich, you are right; the hypervisor is RHEV-H. As Itamar has just explained me, hooks are executed on the hypervisor’s side (not on the RHEV-M, as I used to think), so properly working libguestfs on the RHEV-H will resolve my issue. Here is the output of the test tool: ************************************************************ * IMPORTANT NOTICE * * When