Bug#775761: libguestfs incorrectly detects host CPU architecture
Hi, On Thu, 5 Dec 2019 11:12:56 + "Richard W.M. Jones" wrote: > I believe this is a new bug and nothing much to do with: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775761 So I just cloned the bug into #946594 in order to manage the bug reported by Pierre Neyron. > However about this new bug, what is supposed to happen is that > common/mlstdutils/guestfs_config.ml is generated by ./configure with > the correct @host_cpu@ substituted. If that's not happening then it's > a build issue on Debian of some kind. I closely look at the build system with him. It occurs that : - the Debian package use an 'out-of-source' build (ie the build is *not* done into the source directories) - Debian applies some patches to archive this - but the current rules about guestfs_config.ml especially target the source directory (whereas ./configure generates it in the build directory, as for all other configure generated files) Easy test : - remove common/mlstdutils/guestfs_config.ml in the source directory - build the Debian package (dpkg-buildpackage -us -uc) => the build fails with: ocamlfind ocamlopt -g -annot -safe-string -warn-error CDEFLMPSUVYZX+52-3 -ccopt '-g -O2 -fdebug-prefix-map=/home/polaris/danjean/libguestfs/libguestfs=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-overflow -Wno-strict-overflow' -package str,unix -I . -c ../../../../common/mlstdutils/std_utils.ml -o std_utils.cmx File "_none_", line 1: Warning 58: no cmx file was found in path for module Guestfs_config, and its interface was not compiled with -opaque => the guestfs_config.ml generated in the build directory is not taken into account. => the Debian package is currently using the provided (x86-64) guestfs_config.ml in the source directory and ignore the generated one (in the build directory) on all architectures => the Debian package is correctly built only on x86-64... The root of the problem is in subdir-rules.mk at the root of the package. I found a fix the seems to work: = --- subdir-rules.mk 2019-12-11 15:45:01.274572831 +0100 +++ subdir-rules.mk.fixed 2019-12-11 15:44:23.738419530 +0100 @@ -79,12 +79,12 @@ guestfs_am_v_jar_ = $(guestfs_am_v_jar_@AM_DEFAULT_V@) guestfs_am_v_jar_0 = @echo " JAR " $@; -%.cmi: $(srcdir)/%.mli +%.cmi: %.mli $(guestfs_am_v_ocamlcmi)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) $(OCAMLPACKAGES) -c $< -o $@ -%.cmo: $(srcdir)/%.ml +%.cmo: %.ml $(guestfs_am_v_ocamlc)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) $(OCAMLPACKAGES) -c $< -o $@ if HAVE_OCAMLOPT -%.cmx: $(srcdir)/%.ml +%.cmx: %.ml $(guestfs_am_v_ocamlopt)$(OCAMLFIND) ocamlopt $(OCAMLFLAGS) $(OCAMLPACKAGES) -c $< -o $@ endif = The idea is to let "make" to check itself in the build directory and then in the source directory by not forcing a path and using the VPATH feature (as for all internal automake rules) Looking at the ChangeLog, I saw that the build rules about cmi/cmo/cmx/... seems tricky, so I would prefer that someone that know ocaml builds checks my patch. In any case, the Debian build is broken. As upstream does not seem to support out-of-source build, this problem should not appear for it. So the fix can go into a debian patch (even if I think that my patch is a no-op for a 'in-source' build) Regards, Vincent > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW > > > -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Bug#775761: libguestfs incorrectly detects host CPU architecture
I believe this is a new bug and nothing much to do with: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775761 However about this new bug, what is supposed to happen is that common/mlstdutils/guestfs_config.ml is generated by ./configure with the correct @host_cpu@ substituted. If that's not happening then it's a build issue on Debian of some kind. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
Bug#775761: libguestfs incorrectly detects host CPU architecture -> virt-customize
Hi, I also have an issue with libguestfs incorrectly detecting the host CPU architecture in Debian, when using the virt-customize command on a aarch64 machine. E.g.: neyron@digarm:~/scm/environments-recipes/build/debian-buster-arm64$ virt-customize -a base_debian-buster-arm64.qcow2 --run-command "mkdir /test" [ 0.0] Examining the guest ... [ 11.1] Setting a random seed virt-customize: warning: random seed could not be set for this type of guest [ 11.2] Running: mkdir /test virt-customize: error: host cpu (x86_64) and guest arch (aarch64) are not compatible, so you cannot use command line options that involve running commands in the guest. Use --firstboot scripts instead. If reporting bugs, run virt-customize with debugging enabled and include the complete output: virt-customize -v -x [...] This seems due to the fact that the package is built with the ocaml mlstdutils/guestfs_config host_cpu set to "X86_64", whatever the actual system architechure is. Indeed, when rebuilding the arm64 package with the following patch included, virt-customize works as expected. --- libguestfs-1.40.2.orig/common/mlstdutils/guestfs_config.ml +++ libguestfs-1.40.2/common/mlstdutils/guestfs_config.ml @@ -22,4 +22,4 @@ let package_version = "1.40.2" let package_version_full = "1.40.2" let prefix = "/usr" let datadir = prefix ^ "/share" -let host_cpu = "x86_64" +let host_cpu = "aarch64" However this patch of course will break virt-customize on other archs !. My understanding is that this should be fixed in the packages rules, so that "@host_cpu@" is correctly set with regard to the target arch. But I did not find out how to do that for now. -- System Information: Debian Release: 10.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-6-arm64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libguestfs-tools depends on: ii curl 7.64.0-4 ii libc6 2.29-3 ii libconfig9 1.5-0.4 ii libfuse2 2.9.9-1 ii libguestfs-perl1:1.40.2-2+b12 ii libguestfs01:1.40.2-2+b12 ii libintl-perl 1.26-2 ii libjansson42.12-1 ii liblzma5 5.2.4-1 ii libpcre3 2:8.39-12 ii libreadline8 8.0-3 ii libstring-shellquote-perl 1.04-1 ii libsys-virt-perl 5.6.0-1+b1 ii libtinfo6 6.1+20181013-2+deb10u2 ii libvirt0 5.6.0-2 ii libwin-hivex-perl 1.3.18-2 ii libxml22.9.4+dfsg1-7+b3 Versions of packages libguestfs-tools recommends: ii gnupg 2.2.12-1+deb10u1 libguestfs-tools suggests no packages. -- no debconf information
Bug#775761: libguestfs incorrectly detects host CPU architecture
I wonder why it chose to run /usr/bin/qemu-system-i386 ? Is $LIBGUESTFS_HV or $LIBGUESTFS_QEMU set? What is the output of: guestfish get-hv What happens if you do: LIBGUESTFS_HV=/usr/bin/qemu-system-x86_64 libguestfs-test-tool It looks as if libguestfs is configured wrongly, or maybe you've got the 32 bit version of libguestfs installed on your system. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775761: libguestfs incorrectly detects host CPU architecture
On Tue, Jan 20, 2015 at 07:42:10AM -0800, Rogier wrote: It looks as if libguestfs is configured wrongly, or maybe you've got the 32 bit version of libguestfs installed on your system. I do have a 32-bit version (my entire userland is still 32-bit - it used to be the better choice, and as migrating to 64-bit is a major operation, it is not a high priority...). So the 32-bit version of libguestfs assumes that the qemu version of choice must also be 32 bit, but then it chooses to boot a 64-bit kernel ? You can choose which kernel gets booted by setting up some environment variables. See the manual page here: http://libguestfs.org/supermin.1.html#USING-A-CUSTOM-KERNEL-AND-KERNEL-MODULES Basically just: export SUPERMIN_KERNEL=/boot/my-vmlinuz export SUPERMIN_KERNEL_VERSION=3.XX.0 export SUPERMIN_MODULES=/lib/modules/3.XX.0 Of course, it means you must have a 32 bit kernel for this to work, and supermin will need to find 32 bit binaries and so on. Alternative is to set LIBGUESTFS_HV=/usr/bin/qemu-system-x86_64 which seemed to work for you. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775761: libguestfs incorrectly detects host CPU architecture
Source: libguestfs Version: 1:1.26.9-1 Severity: important Dear Maintainer, When trying to use virt-sparsify, I got the failure message: libguestfs error: guestfs_launch failed Running libguestfs-test-tool shows that libguestfs incorrectly detects the CPU type / architecture. It mentions: This kernel requires an x86-64 CPU, but only detected an i686 CPU. Unable to boot - please use a kernel appropriate for your CPU. See below for the full libguestfs-test-tool output. Both my CPU and my kernel are 64-bit (see below). Virtualisation is also enabled and works fine - I frequently run both 32-bit and 64-bit virtual machines (using: 'qemu-system-x86_64 -enable-kvm') Both qemu-system-i386 and qemu-system-x86_64 are installed on my system. Kind regards, Rogier. (As an aside, on my system, libguestfs-test-tool does not seem to terminate. After printing the messages below, it just hangs. Similarly, virt-ls also seems to hang indefinitely, without producing any output.) libguestfs-test-tool output: -- debian:root ~ 1 # uname -a Linux debian 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux debian:root ~ 2 # which qemu-system-x86_64 /usr/bin/qemu-system-x86_64 debian:root ~ 3 # libguestfs-test-tool *IMPORTANT NOTICE * * When reporting bugs, include the COMPLETE, UNEDITED * output below in your bug report. * PATH=/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin SELinux: sh: 1: getenforce: not found guestfs_get_append: (null) guestfs_get_autosync: 1 guestfs_get_backend: direct guestfs_get_backend_settings: [] guestfs_get_cachedir: /var/tmp guestfs_get_direct: 0 guestfs_get_hv: /usr/bin/qemu-system-i386 guestfs_get_memsize: 500 guestfs_get_network: 0 guestfs_get_path: /usr/lib/i386-linux-gnu/guestfs guestfs_get_pgroup: 0 guestfs_get_program: libguestfs-test-tool guestfs_get_recovery_proc: 1 guestfs_get_selinux: 0 guestfs_get_smp: 1 guestfs_get_tmpdir: /tmp guestfs_get_trace: 0 guestfs_get_verbose: 1 host_cpu: i586 Launching appliance, timeout set to 600 seconds. libguestfs: launch: program=libguestfs-test-tool libguestfs: launch: version=1.26.9 libguestfs: launch: backend registered: unix libguestfs: launch: backend registered: uml libguestfs: launch: backend registered: libvirt libguestfs: launch: backend registered: direct libguestfs: launch: backend=direct libguestfs: launch: tmpdir=/tmp/libguestfsOEAmDG libguestfs: launch: umask=0022 libguestfs: launch: euid=0 libguestfs: [0ms] begin building supermin appliance libguestfs: [0ms] run supermin libguestfs: command: run: /usr/bin/supermin libguestfs: command: run: \ --build libguestfs: command: run: \ --verbose libguestfs: command: run: \ --if-newer libguestfs: command: run: \ --lock /var/tmp/.guestfs-0/lock libguestfs: command: run: \ --copy-kernel libguestfs: command: run: \ -f ext2 libguestfs: command: run: \ --host-cpu i586 libguestfs: command: run: \ /usr/lib/i386-linux-gnu/guestfs/supermin.d libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d supermin: version:
