The documentation for Module::Build is completely opaque on how you're
supposed to pass @CFLAGS@ correctly. However I noticed that we were
not passing -g through when generating Guestfs.so:
gcc -lpthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' '-Wl,--build-id=sha1' -L/usr/local/lib -fstack-protector-strong -lperl -o blib/arch/auto/Sys/Guestfs/Guestfs.so lib/Sys/Guestfs.o -L../lib/.libs -lguestfs
This debuginfo was not always being generated correctly. (For some
reason it still manages to be generated in Fedora and RHEL 9, but not
in RHEL 10, this part is still unclear to me.)
Anyway it seems we ought to pass at least -g to the linker, and we
might as well pass the full set of @CFLAGS@, hence this change.
The actual output of sfdisk --part-attrs is bizarre and doesn't match
the documentation. After looking at the source from util-linux, fix
the parsing to match what sfdisk produces.
Reported-by: Yongkui Guo
Fixes: commit c6c266a85d
Fixes: https://issues.redhat.com/browse/RHEL-35998
Commit d5b6f1df5f ("daemon: Allow parts of the daemon and APIs to be
written in OCaml.", 2017) contained a bug where in any OCaml function
that returns int64_t, the result was truncated to an int. This
particularly affected part_get_gpt_attributes as that returns large 64
bit numbers, but probably affects other functions too, undetected.
Fixes: commit d5b6f1df5f
This was only theoretically supported, via curl. It's unlikely that
it really worked as it was never tested.
If needed it's better to use nbdkit-curl-plugin instead (this applies
to http and ftp as well).
After many, many years, although libvirt does still often fail to
work, it's generally more secure to stick with libvirt than to try
running qemu directly. The main issue here is that people have
cargo-culted LIBGUESTFS_BACKEND=direct everywhere (even when it's not
necessary).
In case network was requested, but the host lacks both dhclient and
dhcpcd, skip the loop which waits for a resolv.conf update.
This reduces boot time by 10 seconds.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
This was failing with recent Linux:
libguestfs: error: btrfs_subvolume_snapshot: /dir/test3: /dir/test6: ERROR: cannot snapshot '/sysroot/dir/test3': Invalid argument
I tried to change the test to use 1/1000 instead, but that fails with
a different error which I don't understand at all.
As we're not meant to be testing btrfs here, only that libguestfs can
translate between the guestfs API and btrfs commands and we know it
can do that, I simply deleted the sub-test entirely.
sfdisk can now do everything with GPT that sgdisk was needed for
before. In particular we are able to reimplement the following
functions using sfdisk:
- part_set_disk_guid (replace with sfdisk --disk-id)
- part_get_disk_guid
- part_set_disk_guid_random
- part_set_gpt_attributes (sfdisk --part-attrs)
- part_get_gpt_attributes
- part_set_gpt_guid (sfdisk --part-uuid)
- part_get_gpt_guid
- part_set_gpt_type (sfdisk --part-type)
- part_get_gpt_type
This allows us to drop the requirement for gdisk in many cases.
There is only one API remaining which requires gdisk, part_expand_gpt,
which we do not use in our tools. In a prior commit I already moved
this solitary function to a new source file (daemon/gdisk.c).
Fixes: https://issues.redhat.com/browse/RHEL-35998
This "new" parameter was added in 2014:
commit 8eab3194ce1737a167812d5e84d83b0dfc253fac
Author: Karel Zak <kzak@redhat.com>
Date: Mon Sep 15 12:37:52 2014 +0200
sfdisk: add --parttype
The patch also makes --{id,change-id,print-id} deprecated in favour
of --parttype. The original --id is too generic option name and the
--print-id and --change-id are unnecessary and inconsistent with
another sfdisk options (e.g. we don't have --change-bootable)
Also remove an extraneous / incorrect comment about parted. As
history has played out, sfdisk proves to be the better tool and parted
is a PITA.
These were regenerated by Dan Berrange from a known good Debian
container image. In addition they are stripped. The commands were:
$ podman run -it registry.gitlab.com/qemu-project/qemu/qemu/debian-loongarch-cross
# echo 'int main(){}' > bin.c
# loongarch64-unknown-linux-gnu-gcc bin.c -o bin-loongarch64
# loongarch64-unknown-linux-gnu-strip --strip-all bin-loongarch64
# echo '' > lib.c
# loongarch64-unknown-linux-gnu-gcc -shared lib.c -o lib-loongarch64.so
# loongarch64-unknown-linux-gnu-strip --strip-all lib-loongarch64.so
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
These binaries are not meant to be run, they are purely data files
used for testing. Remove the +x attribute to prevent accidentally
running them.
However to avoid breaking the phony guests, we need to chmod +x the
files when we upload them into those guests.
guestmount.1 depends on translated files blocksize-option.pod,
key-option.pod & keys-from-stdin-option.pod (via __INCLUDE__
directives). If these are not yet translated by the time we try to
generate guestmount.1 then it will fail with:
podwrapper.pl: key-option.pod: cannot find input file on path at /builddir/build/BUILD/libguestfs-1.50.1/podwrapper.pl line 672.
This happens especially in parallel builds. Fix this by writing the
guestmount.1 rule explicitly, with the correct dependencies.
I noticed that 1-byte translated POD files were being generated in the
output directory (po-docs/ja/). This seems to have happened because
po4a-translate was generating an error, but because we were
immediately pipeing the output into sed the error was suppressed.
By running them as two separate commands this cannot happen.
Fixes: commit bd896d68c0
The previous code split it on ',' which was completely wrong.
(It reveals the lack of testing however).
Fixes: commit c08032ebe2
Reported-by: Yongkui Guo
