similar to: [PATCH] appliance: initialize the appliance_files struct

On Thu, May 04, 2017 at 02:20:28PM +0300, Pavel Butsykin wrote: > This patch changes appliance search using paths with multiple 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

Eric, what do you think of Pavel's analysis and/or suggested fix below? It seems all too plausible to me unfortunately :-( On Fri, May 05, 2017 at 03:46:45PM +0300, Pavel Butsykin wrote: > On 05.05.2017 12:27, Richard W.M. Jones wrote: > > > >Looks good. I'll push this if it passes 'make check && make check-valgrind' > >which I'm currently

NB: This requires a qemu patch by Eduardo which is currently awaiting review: https://www.mail-archive.com/qemu-devel@nongnu.org/msg422959.html So not to be applied yet unless that qemu change goes upstream. Rich.

Sadly, the dhclient-script shipped as part of isc-dhcp-client in Ubuntu unconditionally reads from /etc/fstab without checking for its existence. Since no package holds /etc/fstab, this file will not exist in the appliance, cause dhclient to fail (actually keep looping calling the failing dhclient-script) when the network is requested. As a workaround, touch /etc/fstab just before enabling the

v1 was here: https://www.redhat.com/archives/libguestfs/2020-February/msg00220.html This patch series is a little bit better. It's still a bit of a hack. The _real_ fix for this is outlined in the TODO file (see patch 1) but that requires a lot more work than we could do before 1.42 is released, unless we delay 1.42 for a lot longer. I'm hoping with this to have something which works

The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- This is for Ben Skegg's nouveau tree. I have been working with Karol Herbst on the

Hi guys, During the last few weeks, I've been looking at how to use SPDK as QEMU's bootable rootfs disk. I managed to boot up a SPDK rootfs disk by using OVMF UEFI boot-loader. And in order to deploy the guest OS before start-up(which has a unrecognizable filesystem to the host), I have written a small patch for the libguestfs. It was based on Redhat's CentOS libguestfs-1.36.10 RPM,

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

This function was kind of like debug(), except that it didn't check the g->verbose flag and it only worked in the library (it would crash if used after fork). It also wasn't very useful. The sort of boot analysis done by tests/qemu/boot-analysis.c means that timestamping (some) messages is even less interesting than before. Remove it and replace calls with debug() instead. ---

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

This is only lightly tested. In particularly I only tested that the non-secure-boot path still works. I didn't test it on RHEL 7.3 yet because I haven't got enough free disk space for these giant source *.ova files :-( Will try to give that a go later. Rich.

Signed-off-by: Olaf Hering <olaf@aepfle.de> --- Untested in this environment. appliance/init | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/appliance/init b/appliance/init index b25ea26..cc8c978 100755 --- a/appliance/init +++ b/appliance/init @@ -71,6 +71,10 @@ for f in /sys/block/{h,s,ub,v}d*/queue/scheduler; do echo noop > $f; done # Update the system clock. hwclock -u -s

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

Since v1: - Don't remove the whole of /var/log - Cleanups and fixes to appliance/Makefile.am

Brings the size of the appliance down to 95 MB [xz-compressed], which is the same as for libguestfs 1.28. --- appliance/excludefiles.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/appliance/excludefiles.in b/appliance/excludefiles.in index d3c66cc..a63eca9 100644 --- a/appliance/excludefiles.in +++ b/appliance/excludefiles.in @@ -22,6 +22,9 @@ dnl The right kernel modules are added

Provide /var/lock as symlink to /run/lock, as it might be used by applications. --- appliance/init | 1 + 1 file changed, 1 insertion(+) diff --git a/appliance/init b/appliance/init index b25ea26..aac3f5a 100755 --- a/appliance/init +++ b/appliance/init @@ -32,6 +32,7 @@ mount -t sysfs /sys /sys mkdir -p /run mount -t tmpfs -o "nosuid,size=20%,mode=0755" tmpfs /run mkdir -p

https://bugzilla.redhat.com/show_bug.cgi?id=1165785 Since the --boot option is relatively new (added 2013-12), I suspect this will break older versions of systemd. However it should be fine for all currently supported versions of Fedora. Rich.

Hi, Since I've never succeeded to compile libguestfs from source on Gentoosince the build process of the appliance based on debootstrap fails, I'm wondering how can I tell the compilation process to use a precompiled blob appliance? Also can I use non fedora & debian but use some minimal gentoo based appliance I have? Thanks Alex

Hi! Bernardo, I'm really interested in using that one. Where I can download it from? Thanks, Seung ---- Original message ---- >Date: Tue, 26 Aug 2008 22:56:04 -0700 >From: "Bernardo Elayda" <belayda at gmail.com> >Subject: [LLVMdev] LLVM 2.3 available as a VMware appliance >To: llvmdev at cs.uiuc.edu > > Hi! > > Would there be any interest

Currently if /tmp (on the host) is a symlink, then the symlink is copied into the appliance, probably pointing to a non-existent directory, and everything goes downhill from there. Avoid this by making sure that /tmp and /var/tmp are real directories. --- appliance/init | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/appliance/init b/appliance/init index 3c5ef1b..3973f18 100755 ---