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