On Wed, Nov 29, 2017 at 06:04:06PM +0000, ANDRES POZO MUNOZ wrote:
Hi,
I’m facing some problem trying to install some software in an image with virt-customize.
The package I’m trying to install uses some script to check dependencies and verifies the
linux-headers-4.xxxxx are installed in the guest system.
The problem is that it uses the ‘uname –r’ command to obtain the kernel version, and that
command seems to be replying with the host kernel version instead the guest one.
Could that be the scenario?
Yes, but ...
When the image is booted, the default kernel used is the host’s?
... no.
When the libguestfs / virt-customize appliance is running it uses the
host's highest numbered kernel. Refer to the architecture diagram
here:
http://libguestfs.org/guestfs-internals.1.html#architecture
and the supermin manual:
http://libguestfs.org/supermin.1.html
and run ‘virt-rescue --scratch’ to get a real idea of what's going on.
Later on, when the guest boots for real, it uses its own internal
kernel (which might not even be Linux - virt-customize can customize
Windows guests too!)
Is there any option (via config or something like that) to boot the
image kernel so ‘uname –r’ can provide the right info? (both host
and guest are the same architecture).
I think you're probably better off somehow faking uname or modifying
the installation script.
However in direct answer to this question, yes it is possible to
choose a different appliance kernel by setting SUPERMIN_* environment
variables. Note you must ‘rm -rf /var/tmp/.guestfs-`id -u`’ each time
you change the SUPERMIN_* environment variables.
http://libguestfs.org/supermin.1.html#ENVIRONMENT-VARIABLES
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html