The event callback gets a buffer parameter which is usually something
like a log message. However as it comes from C it is not necessarily
well-formed (eg) UTF-8 but could contain any old sequence of bytes.
In the test case provided by the reporter, we failed to encode the
buffer as 'str' with this error:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 137: unexpected end of data
Use 'bytes' instead. Strictly speaking this changes the type
signature of the callbacks, but our existing Python tests which just
print the buffer using '%s' don't fail and in any case we don't
guarantee the stability of non-C APIs.
Reported-by: Yonatan Shtarkman
See: https://listman.redhat.com/archives/libguestfs/2023-February/030653.html
In the case that building the parameters to the Python event callback
fails, args was returned as NULL. We immediately tried to call
Py_INCREF on this which crashed. Returning NULL means the Python
function threw an exception, so print the exception and return (there
is no way to return an error here - the event is lost).
Reported-by: Yonatan Shtarkman
See: https://listman.redhat.com/archives/libguestfs/2023-February/030653.html
The tool only supports an older version of the diskimage-builder
metadata, and we do not have the time or inclination to update it to a
newer version.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1910039
Run this command across the source:
perl -pi.bak -e 's/(20[012][0-9])-20[12][012]/$1-2023/g' `git ls-files`
and remove changes to po{,-docs}/*.po{,t} (these will be regenerated
later when we run 'make dist').
Update common module to 3253cd99d135d5eb788a0477459b43a269e8cca6
No significant changes that affect virt-v2v now, but it adds some
extra functions to Std_utils that might be used one day.
Cherry picked from virt-v2v commit c7c9dac4f84580190b0e4f7c2e68970192f4bad3
It might be left over from a previous failed run. Best to unlink the
old file before starting qemu-nbd, so there's no possibility of
getting confused later when we wait for the file to appear.
This test fails for reasons I have not fully understood yet. However
one thing I noticed is that the Unix domain socket and PID file used
the tests are placed in the tests/ directory, not the tests/nbd/
subdirectory, so let's fix that:
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -p 63668 ...
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -p 60684 ...
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -k /home/rjones/d/libguestfs-rhel-9.2/tests/unix.sock ...
Fixes: commit 6d32773e81
Add an API to return the build ID of the guest. This to allow a
future change to be able to distinguish between Windows 10 and Windows 11
which can only be done using the build ID.
For Windows we can read the CurrentBuildNumber key from the registry.
For Linux there happens to be a BUILD_ID field in /etc/os-release.
I've never seen a Linux distro that actually uses this.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The file(1) manual suggests using -S (disable seccomp) with -z since
the set of system calls provided by the seccomp policy does not allow
the subprocess to run. This is obvious when you use file -z on a
compressed file on a Linux distro that enables file's seccomp policy
(Arch does this, Fedora does not):
$ file -zbsL lib-i586.so.zst
Bad system call
I also fixed some incorrect text in the manual.
Thanks: Toolybird for pointing to this fix
Reported-by: David Runge
Fixes: https://github.com/libguestfs/libguestfs/issues/100
I cannot reproduce the originally reported error:
libguestfs: error: mkfs: xfs: /dev/VG/LV: Filesystem must be larger than 300MB.
Thanks: David Runge
Related: https://github.com/libguestfs/libguestfs/issues/100
$ ls -l `find -name c-ctype.h`
-rwxr-xr-x. 1 rjones rjones 9647 Dec 3 2021 ./gnulib/lib/c-ctype.h
$ chmod -x `find -name c-ctype.h`
$ ls -l `find -name c-ctype.h`
-rw-r--r--. 1 rjones rjones 9647 Dec 3 2021 ./gnulib/lib/c-ctype.h
RPM builds actually gave a warning about this which is how I noticed
the problem:
*** WARNING: ./usr/src/debug/guestfs-tools-1.48.2-2.fc36.x86_64/gnulib/lib/c-ctype.h is executable but has no shebang, removing executable bit
(cherry picked from
guestfs-tools commit 566267a3d447eb97b4a0637adbe3e45c09ba090f)
Commit 133a491677 ("Use guestfsd binary to auto-generate library
dependencies for appliance", October 2020) removed explicit
dependencies for various system packages that the daemon links
directly to, ie. all of these libraries:
$ objdump -p daemon/guestfsd | grep NEEDED | sort
NEEDED libacl.so.1
NEEDED libaugeas.so.0
NEEDED libcap.so.2
NEEDED libc.so.6
NEEDED libgcc_s.so.1
NEEDED libhivex.so.0
NEEDED libjansson.so.4
NEEDED libm.so.6
NEEDED libpcre2-8.so.0
NEEDED librpm.so.9
NEEDED libselinux.so.1
NEEDED libsystemd.so.0
NEEDED libtirpc.so.3
(plus libyara which I don't have installed.)
This avoids having to update these dependencies if they change, eg.
when we switched from PCRE to PCRE2 we did not need to update this
file.
However the same commit also incorrectly removed two apparent library
packages (libldm, libxml2) which the daemon does not link to, but
which we'd like to pull in because of tools they provide, in
particular ldmtool.
Re-add those two explicit dependencies.
Fixes: commit 133a491677
Many warnings such as:
src/session.c: In function 'guestfs_session_internal_test_rstruct':
src/session.c:14755:7: warning: the comparison will always evaluate as 'true' for the address of 'pv_uuid' will never be NULL [-Waddress]
14755 | if (ret->pv_uuid) memcpy (s->pv_uuid, ret->pv_uuid, sizeof (s->pv_uuid));
| ^~~
In file included from src/session.c:40:
../include/guestfs.h:551:8: note: 'pv_uuid' declared here
551 | char pv_uuid[32]; /* this is NOT nul-terminated, be careful when printing */
| ^~~~~~~
