similar to: [PATCH] appliance: Set $PATH instead of hard-coding paths to binaries everywhere.

--- daemon/guestfsd.c | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c index 21b3600..c9cc8c5 100644 --- a/daemon/guestfsd.c +++ b/daemon/guestfsd.c @@ -243,9 +243,6 @@ main (int argc, char *argv[]) /* Set up a basic environment. After we are called by /init the * environment is essentially

-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -------------- next part -------------- >From 018e8b562b3980a002bd2f9c42cf7dab541ac005 Mon Sep 17

-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -------------- next part -------------- >From 5c6147ecc7ee3cf657edb1e19ad5ab4e973424e0 Mon Sep 17 00:00:00 2001 From: Richard Jones

Replace GUESTFSD_EXT_CMD with a command line option ‘./guestfsd --print-external-commands’

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

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to

In v2: - Kernel command line parsing now moved to the appliance. - In the captive daemon test, the daemon cleanly shuts down on exit. - Add another btrfs test. Rich.

https://bugzilla.redhat.com/show_bug.cgi?id=1477623 The first two patches are cleanups. The third patch changes the way that we handle Device and Dev_or_Path parameters so that a parameter marked as such can really only contain a block device name (and not, for instance, a chardev). Using a chardev here caused hangs in the API. The next two patches fix API usage to conform to this new stricter

If we want to permit more than 255 drives to be added, then we will have to add the disks to the same virtio-scsi target using different unit (LUN) numbers. Unfortunately SCSI LUN enumeration in the Linux is not deterministic (eg. two disks with target=0, lun=[0,1] can be enumerated as /dev/sda or /dev/sdb randomly). Dealing with that will require some very complex device name translation on the

In data martedì 23 giugno 2015 14:34:18, Richard W.M. Jones ha scritto: > --- > daemon/guestfsd.c | 37 +++++++++++++++++++++++-------------- > 1 file changed, 23 insertions(+), 14 deletions(-) > > diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c > index 21b3600..c9cc8c5 100644 > --- a/daemon/guestfsd.c > +++ b/daemon/guestfsd.c > @@ -243,9 +243,6 @@ main (int argc,

This is a simpler patch that removes GUESTFSD_EXT_CMD completely.

On Tue, Sep 30, 2014 at 04:44:04PM +0100, Richard W.M. Jones wrote: > qemu in SLIRP mode offers DHCP services to the appliance. We don't > use them, but use a fixed IP address intead. This changes the > appliance to get its IP address using DHCP. > > Note: This is only used when the network is enabled. dhclient is > somewhat slower, but the penalty (a few seconds) is only

qemu in SLIRP mode offers DHCP services to the appliance. We don't use them, but use a fixed IP address intead. This changes the appliance to get its IP address using DHCP. Note: This is only used when the network is enabled. dhclient is somewhat slower, but the penalty (a few seconds) is only paid for network users. We could consider using the faster systemd dhcp client instead. ---

On Thu, Oct 02, Richard W.M. Jones wrote: > +if grep -sq guestfs_network=1 /proc/cmdline; then > + dhclient > +fi dhclient will be missing at least in openSUSE. Not an issue now, does the script fail if the command fails to execute due to ENOENT? Olaf

On Thu, Oct 02, 2014 at 01:43:46PM +0200, Olaf Hering wrote: > On Thu, Oct 02, Richard W.M. Jones wrote: > > > +if grep -sq guestfs_network=1 /proc/cmdline; then > > + dhclient > > +fi > > dhclient will be missing at least in openSUSE. Not an issue now, does > the script fail if the command fails to execute due to ENOENT? The script won't fail, but the

On Thu, Oct 02, 2014 at 01:53:45PM +0200, Olaf Hering wrote: > On Thu, Oct 02, Richard W.M. Jones wrote: > > > The script won't fail, but the network won't work. What's the > > alternative on SuSE? > > I think that would be dhcpcd, which is also used by NetworkManager. It turns out we don't package dhcpcd in Fedora. If we did the following, would it

On Thu, Oct 02, Richard W.M. Jones wrote: > It seems as if it would, from reading the dhcpcd man page .. Looks like the syntax is 'dhcpcd <interface>'. Olaf

On Thu, Oct 02, 2014 at 02:10:27PM +0200, Olaf Hering wrote: > On Thu, Oct 02, Richard W.M. Jones wrote: > > > It seems as if it would, from reading the dhcpcd man page .. > > Looks like the syntax is 'dhcpcd <interface>'. I haven't tried it of course, but it looks from the man page like dhcpcd will try to configure all interfaces if no interface is

On Thu, Oct 02, Richard W.M. Jones wrote: > The script won't fail, but the network won't work. What's the > alternative on SuSE? I think that would be dhcpcd, which is also used by NetworkManager. Olaf

These 3 patches implement support for APIs which must accept a mountable, but don't update apis which must return mountables. Matt