search for: dispatch_incoming_messag

If you spend your time looking at libguestfs debugging output you'll see many messages from the daemon main loop like this: guestfsd: main_loop: new request, len 0x54 guestfsd: main_loop: proc 278 (mkfs) took 0.02 seconds I don't think these messages really bring much value. This commit removes them entirely. An alternative might be to change them to make them shorter and/or less

Hi Richard, As per your suggestion we removed pango-devel and build was successful. Thank you! After the delivery, our customer reported another error related to virt-resize as below: virt-resize: error: libguestfs error: internal_feature_available: dispatch_incoming_message: unknown procedure number 458, set LIBGUESTFS_PATH to point to the matching libguestfs appliance directory Regards, Abinaya -----Original Message----- From: Richard W.M. Jones [mailto:rjones at redhat.com] Sent: Tuesday, August 29, 2017 7:56 PM To: Abinaya Sandhiya Manikandan (GIS) <abinaya...

On Fri, Sep 01, 2017 at 05:19:06AM +0000, abinaya.manikandan at wipro.com wrote: > virt-resize: error: libguestfs error: internal_feature_available: > dispatch_incoming_message: unknown procedure number 458, set > LIBGUESTFS_PATH to point to the matching libguestfs appliance directory You've mixed up different installations of libguestfs also. Suggest the same resolution as here: https://www.redhat.com/archives/libguestfs/2017-August/msg00140.html Rich. --...

...07, 2017 at 10:10:52AM +0000, emlyn.jose@wipro.com wrote: > Hello Richard, > > Attaching a log file just to check if the issue is with the virt-resize binary. > Kindly have a look at the attached log. The error is: virt-resize: error: libguestfs error: internal_feature_available: dispatch_incoming_message: unknown procedure number 458, set which is caused by and can be fixed if you follow the instructions in this email: https://www.redhat.com/archives/libguestfs/2017-August/msg00140.html Please don't bother me again until you have read the above email. Rich. -- Richard Jones, Virtualiza...

...0 "segv", argc=0, argv=0x4687070) at debug.c:223 223\tdebug.c: No such file or directory. #0 debug_segv (subcmd=0x4687050 "segv", argc=0, argv=0x4687070) at debug.c:223 #1 0x000000000042e083 in debug_stub (xdr_in=<optimized out>) at stubs.c:2557 #2 0x0000000000448d5d in dispatch_incoming_message (xdr_in=0x7fffffffe8d0) at stubs.c:15819 #3 0x0000000000428a91 in main_loop (_sock=73953360, _sock at entry=3) at proto.c:192 #4 0x000000000040564d in main (argc=<optimized out>, argv=<optimized out>) at guestfsd.c:344 Rebooting. Rich. -- Richard Jones, Virtualization Group, Red...

https://bugzilla.redhat.com/show_bug.cgi?id=755729 This bug reports that the error message printed by the resize2fs API calls (which comes directly from the resize2fs command) says: Please run 'e2fsck -f /dev/vda1' first. That command is not possible from guestfish (where it would be 'e2fsck-f' or 'e2fsck ... forceall:true'). Fixing that bug caused this bug:

By splitting up large C files we can make parallel compiles a bit faster. Rich.

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

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

Split up the huge generator/actions.ml into several smaller files. Rich.