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-L52 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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
