On Thu, Jul 21, 2016 at 04:54:46PM +0800, Chen Hanxiao wrote: > > Hi, Rich: > > I met a supermin issue on CentOS 7.1: > > supermin: version: 5.1.10 > supermin: rpm: detected RPM version 4.11 > supermin: package handler: fedora/rpm > supermin: acquiring lock on /root/test/aaa/lock > supermin: build: /usr/lib64/guestfs/supermin.d > supermin: build: visiting /usr/lib64/guestfs/supermin.d/base.tar.gz type gzip base image (tar) > supermin: build: visiting /usr/lib64/guestfs/supermin.d/daemon.tar.gz type gzip base image (tar) > supermin: build: visiting /usr/lib64/guestfs/supermin.d/excludefiles type uncompressed excludefiles > supermin: build: visiting /usr/lib64/guestfs/supermin.d/hostfiles type uncompressed hostfiles > supermin: build: visiting /usr/lib64/guestfs/supermin.d/init.tar.gz type gzip base image (tar) > supermin: build: visiting /usr/lib64/guestfs/supermin.d/packages type uncompressed packages > supermin: build: visiting /usr/lib64/guestfs/supermin.d/udev-rules.tar.gz type gzip base image (tar) > supermin: build: 185 packages, including dependencies > supermin: build: 30676 files > supermin: build: 17495 files, after removing unreadable files > supermin: build: 8834 files, after matching excludefiles > supermin: build: 8840 files, after adding hostfiles > supermin: build: 8870 files, after munging > supermin: kernel: picked kernel vmlinuz-3.10.0-229.el7.x86_64 > supermin: kernel: picked modules path /lib/modules/3.10.0-229.el7.x86_64 > supermin: kernel: kernel_version 3.10.0-229.el7.x86_64 > supermin: kernel: modules /lib/modules/3.10.0-229.el7.x86_64 > supermin: ext2: creating empty ext2 filesystem '/root/test/aaa.8v6mujxm/root' > supermin: ext2: populating from base image > supermin: ext2: copying files from host filesystem > supermin: ext2: copying kernel modules > supermin: ext2: creating minimal initrd '/root/test/aaa.8v6mujxm/initrd' > supermin: ext2: wrote 0 modules to minimal initrd > ^ > | > > It seam that supermin failed to write modules into initrd. That doesn't look good! What is supposed to happen here is that the modules path (/lib/modules/3.10.0-229.el7.x86_64) is searched in order to find any modules matching one of these patterns: https://github.com/libguestfs/supermin/blob/master/src/ext2_initrd.ml#L33... You could try doing for example: find /lib/modules/3.10.0-229.el7.x86_64/ -name 'ext4.ko*' BTW this isn't always a problem. It could be that you are using a self-compiled CentOS kernel which doesn't have any modules (eg. everything is compiled into the kernel). If libguestfs still works, then there's nothing to worry about. However I am not aware of any CentOS distributed kernels which are configured like that.

You can also try choosing a different kernel, by setting: export SUPERMIN_KERNEL_VERSION=3.10.0-123.el7.x86_64 export SUPERMIN_KERNEL=/boot/vmlinuz-$SUPERMIN_KERNEL_VERSION export SUPERMIN_MODULES=/lib/modules/$SUPERMIN_KERNEL_VERSION > But it works fine on another centos 7.1 machine. > > Could you please give me some hints on how to debug this kind of issue? You can get more debugging by adding more -v options, eg: supermin5 --build -f ext2 -v -v -v /usr/lib64/guestfs/supermin.d -o /tmp/appliance.d The effect of using -v multiple times is to increase the "debug" setting in the code, so more messages may be printed, for example: https://github.com/libguestfs/supermin/blob/master/src/ext2_initrd.ml#L62 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

On Thu, Jul 21, 2016 at 06:36:20PM +0800, Chen Hanxiao wrote: > the virtio modules in kmods did existed in this machine. > with -v -v -v, I got: Can you attach or pastebin the complete output from this command on the failing machine please: supermin5 --build -f ext2 -v -v -v /usr/lib64/guestfs/supermin.d -o /tmp/appliance.d

On Thu, Jul 21, 2016 at 06:50:52PM +0800, Chen Hanxiao wrote: > > > At 2016-07-21 18:43:04, "Richard W.M. Jones" <rjones(a)redhat.com&gt; wrote: > >On Thu, Jul 21, 2016 at 06:36:20PM +0800, Chen Hanxiao wrote: > >> the virtio modules in kmods did existed in this machine. > >> with -v -v -v, I got: > > > >Can you attach or pastebin the complete output from this command on > >the failing machine please: > > > >supermin5 --build -f ext2 -v -v -v /usr/lib64/guestfs/supermin.d -o /tmp/appliance.d > > > > Sure. > > Please check the attachments. I'm not exactly sure what's wrong. There are two things you can try: (1) Upgrade to a later supermin. The latest version is 5.1.16, which is available here: https://people.redhat.com/~rjones/libguestfs-RHEL-7.3-preview/ It is also much faster than 5.1.10.

(2) With 5.1.16, if it still doesn't work, strace it, and let us see the full strace.log: strace -o /tmp/strace.log -s 1024 \ supermin5 --build -f ext2 -v -v -v /usr/lib64/guestfs/supermin.d \ -o /tmp/appliance.d 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/

On Thu, Jul 21, 2016 at 07:31:51PM +0800, Chen Hanxiao wrote: > > Hi, Rich: > > I download the rpm from > https://people.redhat.com/~rjones/libguestfs-RHEL-7.3-preview/supermin5-5... > > and exact it Please install it using yum: # cat > /etc/yum.repos.d/libguestfs-RHEL-7.3-preview.repo <<EOF [libguestfs-RHEL-7.3-preview] name=libguestfs RHEL 7.3 preview baseurl=http://people.redhat.com/~rjones/libguestfs-RHEL-7.3-preview/ enabled=1 gpgcheck=0 EOF # yum install supermin5 # supermin5 --version > But > #supermin -V > supermin 4.1.4 > > supermin: unknown option `--build'. > supermin - tool for creating supermin appliances > Copyright (C) 2009-2013 Red Hat Inc. > > Anything wrong? On RHEL and CentOS 7 the tool is called 'supermin5'.

On Thursday, 21 July 2016 18:50:52 CEST Chen Hanxiao wrote: > > At 2016-07-21 18:43:04, "Richard W.M. Jones" <rjones(a)redhat.com&gt; wrote: > >On Thu, Jul 21, 2016 at 06:36:20PM +0800, Chen Hanxiao wrote: > >> the virtio modules in kmods did existed in this machine. > >> with -v -v -v, I got: > > > >Can you attach or pastebin the complete output from this command on > >the failing machine please: > > > >supermin5 --build -f ext2 -v -v -v /usr/lib64/guestfs/supermin.d -o /tmp/appliance.d > > > > Sure. > > Please check the attachments. Hm, is the /lib/modules/3.10.0-229.el7.x86_64/modules.dep file correct (as in existing and not empty)? If so, what if you run as root `depmod -a` and then try again?

Thanks for your hint. I think we got the key: on the machine fail: we lack of lines like: kernel/drivers/char/hw_random/amd-rng.ko: kernel/drivers/char/hw_random/via-rng.ko: kernel/drivers/char/hw_random/virtio-rng.ko: kernel/drivers/virtio/virtio_ring.ko kernel/drivers/virtio/virtio.ko kernel/drivers/char/hw_random/tpm-rng.ko: kernel/drivers/char/tpm/tpm_nsc.ko: kernel/drivers/char/tpm/tpm_atmel.ko: kernel/drivers/char/tpm/tpm_infineon.ko: kernel/drivers/char/virtio_console.ko: kernel/drivers/virtio/virtio_ring.ko kernel/drivers/virtio/virtio.ko ... which existed on the machine works fine. It works fine now. But why we make initrd only depends on modules.dep?