It's unclear why exactly the OCaml library is using replacement
symbols, but it is so we need gnulib. Note this only applies in the
stable-1.44 branch since upstream we have finally got rid of gnulib,
because of exactly these kinds of problems that it causes everyone.
ocamlfind ocamlopt -cclib -L../../lib/.libs -package unix -linkpkg \
-warn-error A -I .. mlguestfs.cmxa create_disk.ml -o create_disk
../libmlguestfs.a(libguestfsocaml_a-guestfs-c.o): In function `guestfs_finalize':
/home/rjones/d/libguestfs-1.44/ocaml/guestfs-c.c:86: undefined reference to `rpl_free'
/home/rjones/d/libguestfs-1.44/ocaml/guestfs-c.c:88: undefined reference to `rpl_free'
../libmlguestfs.a(libguestfsocaml_a-guestfs-c.o): In function `guestfs_int_ocaml_set_event_callback':
/home/rjones/d/libguestfs-1.44/ocaml/guestfs-c.c:239: undefined reference to `rpl_free'
../libmlguestfs.a(libguestfsocaml_a-guestfs-c.o): In function `guestfs_int_ocaml_delete_event_callback':
/home/rjones/d/libguestfs-1.44/ocaml/guestfs-c.c:266: undefined reference to `rpl_free'
../libmlguestfs.a(libguestfsocaml_a-guestfs-c.o): In function `guestfs_int_ocaml_event_to_string':
/home/rjones/d/libguestfs-1.44/ocaml/guestfs-c.c:290: undefined reference to `rpl_free'
../libmlguestfs.a(libguestfsocaml_a-guestfs-c-actions.o):/home/rjones/d/libguestfs-1.44/ocaml/guestfs-c-actions.c:1188: more undefined references to `rpl_free' follow
collect2: error: ld returned 1 exit status
File "caml_startup", line 1:
Error: Error during linking
make[2]: *** [Makefile:2272: create_disk] Error 2
The daemon failed to link with glibc < 2.34 because we didn't include
the separate pthread library. Adding -pthread fixes this.
Note this change was also make upstream in commit 733d2182b6 ("Remove
the tools.") although I think either by accident or unrelated.
Reported-by: Toolybird
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2003326
When using LTO, inlining something (I'm unclear what exactly) causes
these errors:
stubs-1.c: In function 'md_create_stub':
stubs-1.c:1929:1: error: stack usage might be unbounded [-Werror=stack-usage=]
1929 | md_create_stub (XDR *xdr_in)
| ^
stubs-0.c: In function 'mkfs_btrfs_stub':
stubs-0.c:1984:1: error: stack usage might be unbounded [-Werror=stack-usage=]
1984 | mkfs_btrfs_stub (XDR *xdr_in)
| ^
stubs-3.c: In function 'btrfs_device_delete_stub':
stubs-3.c:477:1: error: stack usage might be unbounded [-Werror=stack-usage=]
477 | btrfs_device_delete_stub (XDR *xdr_in)
| ^
stubs-3.c: In function 'btrfs_image_stub':
stubs-3.c:694:1: error: stack usage might be unbounded [-Werror=stack-usage=]
694 | btrfs_image_stub (XDR *xdr_in)
| ^
stubs-5.c: In function 'btrfs_device_add_stub':
stubs-5.c:247:1: error: stack usage might be unbounded [-Werror=stack-usage=]
247 | btrfs_device_add_stub (XDR *xdr_in)
| ^
Note this is only for the stable branch.
Lots of variations of this. It cannot happen because we check that
section != NULL just before calling this code.
'parse_xfs_info': event 41
|
|../lib/guestfs-internal-all.h:50:21:
| 50 | #define STREQ(a,b) (strcmp((a),(b)) == 0)
| | ^~~~~~~~~~~~~~~
| | |
| | (41) argument 1 ('section') from (35) could be NULL where non-null expected
xfs.c:186:13: note: in expansion of macro 'STREQ'
| 186 | if (STREQ (section, "meta-data")) {
| | ^~~~~
|
Similarly this error does not appear possible:
xfs.c:154:7: error: double-'free' of 'ret_9' [CWE-415] [-Werror=analyzer-double-free]
154 | free (section);
| ^
See comment for why these suppressions are placed centrally.
In file included from launch-libvirt.c:49:
launch-libvirt.c: In function 'add_secret':
launch-libvirt.c:1956:54: error: pointer targets in passing argument 5 of 'base64_decode_alloc_ctx' differ in signedness [-Werror=pointer-sign]
1956 | (char **) &secret_raw, &secret_raw_len)) {
| ^~~~~~~~~~~~~~~
| |
| size_t * {aka long unsigned int *}
../gnulib/lib/base64.h:62:56: note: in definition of macro 'base64_decode_alloc'
62 | base64_decode_alloc_ctx (NULL, in, inlen, out, outlen)
| ^~~~~~
../gnulib/lib/base64.h:56:57: note: expected 'idx_t *' {aka 'long int *'} but argument is of type 'size_t *' {aka 'long unsigned int *'}
56 | char **out, idx_t *outlen);
| ~~~~~~~^~~~~~
cc1: all warnings being treated as errors
Note this patch is only required in the stable branch because
of the gnulib update.
This warning is bogus, caused by the analyzer cannot track that len ==
0 if roots == NULL. I just changed the code to make it easier to
analyze, this doesn't fix any real bug.
guestfs-c.c: In function 'guestfs_finalize':
guestfs-c.c:85:9: error: dereference of NULL '0B' [CWE-476] [-Werror=analyzer-null-dereference]
85 | caml_remove_generational_global_root (roots[i]);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(cherry picked from commit ea04d6b878)
Found by GCC -fanalyzer:
xattr.c:478:32: error: '%zu' directive output may be truncated writing between 1 and 19 bytes into a region of size 16 [-Werror=format-truncation=]
478 | snprintf (num, sizeof num, "%zu", nr_attrs);
| ^
xattr.c:478:32: note: directive argument in the range [0, 2305843009213693950]
/usr/include/bits/stdio2.h:71:10: note: '__builtin___snprintf_chk' output between 2 and 20 bytes into a destination of size 16
71 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^
(cherry picked from commit 58599031f8)
Each worker thread of "test-parallel-mount-local" performs the following
steps (among others):
(1) it starts an appliance dedicated to that thread, using a private
scratch disk image,
(2) exports a dedicated FUSE mount point on the host, exposing the file
system on the appliance's disk,
(3) launches a child process for manipulating the particular FUSE mount
point on the host,
(4) enters a FUSE request processing loop, translating requests between
the host kernel (coming in via the FUSE mount point) and the
appliance.
Items to note:
- The child process from step (3) consists of a single thread of execution
(see fork() in POSIX): a duplicate of the parent process's respective
worker thread.
- The child process from step (3) blocks on any FUSE mount point access on
the host until the worker thread in the parent process starts processing
FUSE requests, in step (4).
- The FUSE request processing in step (4), in the worker thread living in
the parent process, terminates if and only if the child process unmounts
the FUSE mount point originating from (2).
Should the exec call in step (3) fail for any reason, the child currently
jumps to the "error" label. This is wrong: under the error label, we call
guestfs_close() on the appliance -- but the appliance is owned by the
parent process's worker thread, not the child. What happens is that the
child kills off the appliance while the parent's worker thread is in the
FUSE request processing loop (4).
The "error" label was never meant to be reached by the child process -- if
exec fails for any reason, exit the child immediately. The parent will
remain in the FUSE request processing loop (4) forever, but no state will
be corrupted. For example, using another (interactive) session on the
host, the FUSE mount points can be interacted with, and if all of them are
manually unmounted, the FUSE request processing (4) completes in every
worker thread.
This patch does not fix the primary issue with
"test-parallel-mount-local", but removes "chaos" from the symptoms. The
next patch will fix the actual regression in this test case.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210902135124.15191-2-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
(cherry picked from commit 79d7fc8674)
If /lib is a symlink to usr/lib, paths to shared libraries as
determined by ld.so may differ from dpkg's file lists.
We turn the filename search pattern into a glob expression by
prefixing it with a '*', so the required packages are found again:
$ dpkg -S /lib/x86_64-linux-gnu/libpcre2-8.so.0
dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/libpcre2-8.so.0
$ dpkg -S */lib/x86_64-linux-gnu/libpcre2-8.so.0
libpcre2-8-0:amd64: /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
(cherry picked from commit 39f514b28d)
qemu 6.1 has decided to change qemu-img create so that a backing
format (-F) is required if a backing file (-b) is specified. Since we
don't want to change the libguestfs API to force callers to specify
this because that would be an API break, autodetect it.
This is similar to commit c8c181e8d9 ("launch: libvirt: Autodetect
backing format for readonly drive overlays").
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1998820
(cherry picked from commit 45de287447)
When using option `--with-distro`, `HAVE_RPM`, `HAVE_DPKG` and
`HAVE_PACMAN` are not defined and make the configure phase fail.
This makes sure that these conditionals are always defined.
(cherry picked from commit 210959cc34)
Windows Server 2022 preview is identified as <osinfo>win2k16</osinfo>.
Although current osinfo-db does not have an entry "win2k22", return
this instead.
osinfo-db issue to add win2k22:
https://gitlab.com/libosinfo/osinfo-db/-/issues/82
Inspection information for the guest:
type: windows
distro: windows
product_name: Windows Server 2022 Datacenter
product_variant: Server
version: 10.0
arch: x86_64
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1997446
Reported-by: Yongkui Guo
(cherry picked from commit 73cd0a0c8d)
On RISC-V there is no default machine type. Invoking QEMU requires to
specify a board model with the -M option. So let's define MACHINE_TYPE
as virt.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
(cherry picked from commit efb3d01992)
$ guestfish -N fs:vfat:2G syslinux /dev/sda1
libguestfs: error: syslinux: Error converting to codepage 850 Invalid argument
...
This happens because of the default codepage requested by syslinux
(code page 850) combined with the appliance missing the iconv
converter for this codepage.
Reported-by: Yongkui Guo
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1990720
(cherry picked from commit 90a076fe19)
When creating and returning a Python struct we were adding fields from
the C struct, but did not reduce the ref count on the temporary value
after it had been moved to the struct, resulting in a memory leak.
Reported-by: 朱丹 <zhudan24@huawei.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1985912
(cherry picked from commit e84c63a2ca)
The `test` builtin/binary usually accepts `==` for string comparison, it is
mostly accepted for typos and people being used to double equals, but is not
documented and not always accepted either. Since autoconf uses the default
shell, it might just fail in some cases with:
./configure: 29986: test: xrustc: unexpected operator
./configure: 29990: test: xcargo: unexpected operator
Just change it to single equals as it is done everywhere else.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
(cherry picked from commit e68a844eb4)
warning: panic message is not a string literal
--> src/bin/event_leak.rs:9:30
|
9 | Err(e) => panic!(format!(" could not create handle {:?}", e)),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(non_fmt_panic)]` on by default
= note: this is no longer accepted in Rust 2021
= note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
(cherry picked from commit d01ce08218)
QEMU has deprecated this option:
commit 166310299a1e7824bbff17e1f016659d18b4a559
Author: Daniel P. Berrangé
Date: Tue Oct 20 17:08:27 2020 +0100
os: deprecate the -enable-fips option and QEMU's FIPS enforcement
The -enable-fips option was added a long time ago to prevent the use of
single DES when VNC when FIPS mode is enabled. It should never have been
added, because apps are supposed to unconditionally honour FIPS mode
based on the '/proc/sys/crypto/fips_enabled' file contents.
In addition there is more to achieving FIPS compliance than merely
blocking use of certain algorithms. Those algorithms which are used
need to perform self-tests at runtime.
QEMU's built-in cryptography provider has no support for self-tests,
and neither does the nettle library.
If QEMU is required to be used in a FIPS enabled host, then it must be
built with the libgcrypt library enabled, which will unconditionally
enforce FIPS compliance in any algorithm usage.
Thus there is no need to keep either the -enable-fips option in QEMU, or
QEMU's internal FIPS checking methods.
(cherry picked from commit d3bbc02190)
In RHEL 8+, /usr/etc no longer exists. Since we were looking for this
directory in order to detect a separate /usr partition, those were no
longer detected, so the merging of /usr data into the root was not
being done. The result was incomplete inspection data and failure of
virt-v2v.
All Linux systems since forever have had /usr/src but not /src, so
detect this instead.
Furthermore the merging code didn't work, because we expected that the
root filesystem had a distro assigned, but in this configuration we
may need to look for that information in /usr/lib/os-release (not on
the root filesystem). This change makes the merging work even if we
have incomplete information about the root filesystem, so long as we
have an /etc/fstab entry pointing to the /usr mountpoint.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1949683
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1930133
Fixes: commit 394d11be49
(cherry picked from commit 26427b9ecc)
./guestfs.go:4945:16: conversion from _Ctype_char (int8) to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?)
./guestfs.go:7320:16: conversion from _Ctype_char (int8) to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?)
./guestfs.go:7335:16: conversion from _Ctype_char (int8) to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?)
(cherry picked from commit 93c2d09136)
The child (chrooted) process wrote its answer on the pipe and then
exited. Meanwhile the parent waiting for the child to exit before
reading from the pipe. Thus if the output was larger than a Linux
pipebuffer then the whole thing would deadlock.
(cherry picked from commit 94e64b28be)
Latest btrfs seems to reject 512 byte sector size. It may be because
of the specific hardware that I'm running the test on. Anyway using a
4K sector size works.
libguestfs: error: mkfs_btrfs: /dev/sda1: ERROR: invalid sectorsize 512, expected range is [4K, 64K]
(cherry picked from commit 48a35c117e)
This was returning "readdir: Invalid argument" which is actually
impossible (readdir(3) cannot fail with EINVAL). It turns out that
the problem is just errno from some other place leaking out.
(cherry picked from commit e0a1106103)
