search for: appliances

v1 was here: https://www.redhat.com/archives/libguestfs/2016-March/thread.html#00157 Not running the 'hwclock' command reduces boot times considerably. However I'm not sure if it is safe. See the question I posted on qemu-devel: http://thread.gmane.org/gmane.comp.emulators.qemu/402194 At the moment, about 50% of the time is consumed by SeaBIOS. Of this, about ⅓rd is SGABIOS

...performance(1)>). =back -For deeper understanding of why you might need this tool, read the -section L</FIXED APPLIANCE> below. +For deeper understanding of why you might need this tool, read +L<guestfs(3)/FIXED APPLIANCE>. Instead of running this tool, you can download fixed appliances from L<http://libguestfs.org/download/binaries/appliance/>. These @@ -120,30 +120,6 @@ completely silent when it is running. =back -=head1 FIXED APPLIANCE - -When libguestfs (or libguestfs tools) are run, they search a path -looking for an appliance. The path is built into libguestfs,...

...performance(1)>). =back -For deeper understanding of why you might need this tool, read the -section L</FIXED APPLIANCE> below. +For deeper understanding of why you might need this tool, read +L<guestfs(3)/FIXED APPLIANCE>. Instead of running this tool, you can download fixed appliances from L<http://libguestfs.org/download/binaries/appliance/>. These @@ -120,30 +120,6 @@ completely silent when it is running. =back -=head1 FIXED APPLIANCE - -When libguestfs (or libguestfs tools) are run, they search a path -looking for an appliance. The path is built into libguestfs,...

...performance(1)>). =back -For deeper understanding of why you might need this tool, read the -section L</FIXED APPLIANCE> below. +For deeper understanding of why you might need this tool, read +L<guestfs(3)/FIXED APPLIANCE>. Instead of running this tool, you can download fixed appliances from L<http://libguestfs.org/download/binaries/appliance/>. These @@ -120,30 +120,6 @@ completely silent when it is running. =back -=head1 FIXED APPLIANCE - -When libguestfs (or libguestfs tools) are run, they search a path -looking for an appliance. The path is built into libguestfs,...

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 WIP (the most...

Some compilers do not manage to figure out that the members of it are set only when search_appliance() in the end returns 1, which is already checked. Help them a bit by resetting the appliance_files struct on our own, so they will not report that 'appliance.kernel', and the others are used as uninitialized. --- lib/appliance.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 1/3] Add a core_pattern debug command The first patch is just a rework of Rich's earlier core dump patch. It turns it into a debug subcommand so it can be called at any time. This also has the advantage of explicitly labelling an extremely untidy API as debug. [PATCH 2/3] Call sync after guestfsd exits The second patch seems to be required for cores to be dumped reliably. I was able to

This is a repost of a previously posted set. It's been updated following review comments. [PATCH 1/4] Add a core_pattern debug command Added missing return statements. [PATCH 2/4] Call sync after guestfsd exits Remove redundant sleep 1; sync [PATCH 3/4] Shut down the appliance cleanly [PATCH 4/4] Ignore launch() error in virt-rescue These were previously 2 patches. They are otherwise

Hi, I am getting a weird libguestfs failure from time to time: 2020-08-27 08:48:40 T libguestfs - 0 - appliance - SeaBIOS (version 1.12.0-1) 2020-08-27 08:48:40 T libguestfs - 0 - appliance - Booting from ROM... 2020-08-27 08:48:40 T libguestfs - 0 - library - child_cleanup: 0xd5a840: child process died Let me elaborate more about my environment I am running libguestfs 1.42.0 on GCP -

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

...directories. Now > all appliance checks will be done separately for each directory. For example > if the path LIBGUESTFS_PATH=/a:/b:/c, then all applainces are searched first in > /a, then in /b and then in /c. It allows to flexibly configure the libguestfs > to interact with different appliances. > > Signed-off-by: Pavel Butsykin <pbutsykin@virtuozzo.com> > --- > lib/appliance.c | 231 ++++++++++++++++++++++++++------------------------------ > 1 file changed, 108 insertions(+), 123 deletions(-) > > diff --git a/lib/appliance.c b/lib/appliance.c > index f12...

To allow easier downstream tweaks to the virt-rescue welcome message, just output the content of the /etc/issue file in the appliance. Thus, a new extras.tar.gz file appeared in supermin.d containing the etc/issue file and future tweaks like this one. --- appliance/Makefile.am | 11 +++++++++++ appliance/init | 11 ++--------- appliance/issue | 9 +++++++++ 3 files changed, 22

...appliance containing the packages C<bash> and C<coreutils>. Specifically, it creates some files in directory -C<supermin.d>. This directory I<is> the supermin appliance. (See +F<supermin.d>. This directory I<is> the supermin appliance. (See L</SUPERMIN APPLIANCES> below). It is intended that the I<--prepare> step is done on a central build @@ -60,8 +60,8 @@ builds the full appliance from the supermin appliance: supermin --build --format ext2 supermin.d -o appliance.d -This will create files called C<appliance.d/kernel>, -C<applian...

--- appliance/excludefiles.in | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/appliance/excludefiles.in b/appliance/excludefiles.in index 9a48db7..c53a913 100644 --- a/appliance/excludefiles.in +++ b/appliance/excludefiles.in @@ -32,12 +32,7 @@ dnl The right kernel modules are added back by supermin. -/usr/share/i18n/* -/usr/share/pkgconfig/* --/var/log/*.log*

Currently when the appliance is booted we see warning messages like these ones: [/usr/lib/tmpfiles.d/systemd.conf:26] Failed to replace specifiers: /run/log/journal/%m [/usr/lib/tmpfiles.d/systemd.conf:28] Failed to replace specifiers: /run/log/journal/%m [/usr/lib/tmpfiles.d/systemd.conf:29] Failed to replace specifiers: /run/log/journal/%m They are apparently harmless, but are caused because

For the appliance of the QCOW2 format, get the UUID of the disk by reading the first 256k bytes with 'qemu-img dd' command. Then pass the read block to the 'file' command. In case of failure, run the 'file' command again directly. Suggested-by: Denis V. Lunev <den@openvz.org> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> --- v2: 01: 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. > 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 p...

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

This is largely code motion. --- src/appliance.c | 40 +++++++----------------------------- src/guestfs-internal.h | 1 + src/tmpdirs.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 63 insertions(+), 33 deletions(-) diff --git a/src/appliance.c b/src/appliance.c index 2cf6374..d293c2b 100644 --- a/src/appliance.c +++ b/src/appliance.c @@ -48,7 +48,7

For the appliance of the QCOW2 format, the function get_root_uuid() fails to get the UUID of the disk image. In this case, let us read the first 256k bytes of the disk image with the 'qemu-img dd' command. Then pass the read block to the 'file' command. Suggested-by: Denis V. Lunev <den@openvz.org> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> ---