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: [00000ms] begin building supermin appliance
libguestfs: [00000ms] 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: 5.1.10
supermin: package handler: debian/dpkg
supermin: acquiring lock on /var/tmp/.guestfs-0/lock
supermin: if-newer: output does not need rebuilding
libguestfs: [00006ms] finished building supermin appliance
libguestfs: [00006ms] begin testing qemu features
libguestfs: command: run: /usr/bin/qemu-system-i386
libguestfs: command: run: \ -display none
libguestfs: command: run: \ -help
libguestfs: command: run: /usr/bin/qemu-system-i386
libguestfs: command: run: \ -display none
libguestfs: command: run: \ -version
libguestfs: qemu version 2.1
libguestfs: command: run: /usr/bin/qemu-system-i386
libguestfs: command: run: \ -display none
libguestfs: command: run: \ -machine accel=kvm:tcg
libguestfs: command: run: \ -device ?
libguestfs: [00122ms] finished testing qemu features
[00123ms] /usr/bin/qemu-system-i386 \
    -global virtio-blk-pci.scsi=off \
    -nodefconfig \
    -enable-fips \
    -nodefaults \
    -display none \
    -machine accel=kvm:tcg \
    -m 500 \
    -no-reboot \
    -rtc driftfix=slew \
    -no-hpet \
    -global kvm-pit.lost_tick_policy=discard \
    -kernel /var/tmp/.guestfs-0/appliance.d/kernel \
    -initrd /var/tmp/.guestfs-0/appliance.d/initrd \
    -device virtio-scsi-pci,id=scsi \
    -drive file=/tmp/libguestfsOEAmDG/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \
    -device scsi-hd,drive=hd0 \
    -drive file=/var/tmp/.guestfs-0/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \
    -device scsi-hd,drive=appliance \
    -device virtio-serial-pci \
    -serial stdio \
    -device sga \
    -chardev socket,path=/tmp/libguestfsOEAmDG/guestfsd.sock,id=channel0 \
    -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
    -append 'panic=1 noapic console=ttyS0 udevtimeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm'
\x1b[1;256r\x1b[256;256H\x1b[6n
Google, Inc.
Serial Graphics Adapter 12/07/13
SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ (mjt@gandalf) Sat Dec  7 15:39:53 UTC 2013
Term: 80x24
4 0
SeaBIOS (version 1.7.5-20140531_083030-gandalf)
Booting from ROM...
This kernel requires an x86-64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU.
^C
----------------------------------------------------------------------

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.

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.

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.

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.

  Hi,

  So I just cloned the bug into #946594 in order to manage the bug reported
by Pierre Neyron.
- 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