How to debug supermin5 issue?
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. 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? Thanks in advance. Regards, - Chen
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-L5... 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
At 2016-07-21 17:45:13, "Richard W.M. Jones" <rjones@redhat.com> wrote:
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-L5...
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.
Hi, Rich. Thanks for your quick reply. the virtio modules in kmods did existed in this machine. with -v -v -v, I got: ... supermin: build: excluding /lib/modules/3.10.0-229.el7.x86_64/kernel/drivers/scsi/virtio_scsi.ko ... supermin: ext2: copy_file /lib/modules/3.10.0-229.el7.x86_64/kernel/drivers/scsi/virtio_scsi.ko -> /lib/modules/3.10.0-229.el7.x86_64/kernel/drivers/scsi/virtio_scsi.ko ... Then I got: supermin: ext2: copy_file /lib/modules/3.supermin: ext2: creating minimal initrd '/root/test/aaa.lopr92ap/initrd' supermin: ext2: wrote 0 modules to minimal initrd But did not got this kind of log: supermin: ext2: initrd: visiting module kernel/drivers/scsi/virtio_scsi.ko Which found on the machine supermin works fine. It looks strange. Regards, - Chen
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 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
At 2016-07-21 18:43:04, "Richard W.M. Jones" <rjones@redhat.com> 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. Regards, - Chen
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@redhat.com> 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/
At 2016-07-21 19:04:07, "Richard W.M. Jones" <rjones@redhat.com> wrote:
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@redhat.com> 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.
Hi, Rich: I download the rpm from https://people.redhat.com/~rjones/libguestfs-RHEL-7.3-preview/supermin5-5.1.... and exact it 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? Regards, - Chen
(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:
At 2016-07-21 19:04:07, "Richard W.M. Jones" <rjones@redhat.com> wrote:
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@redhat.com> 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.
Hi, Rich:
I download the rpm from https://people.redhat.com/~rjones/libguestfs-RHEL-7.3-preview/supermin5-5.1....
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'. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
At 2016-07-21 19:37:19, "Richard W.M. Jones" <rjones@redhat.com> wrote:
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.1....
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'.
Hi, Rich Thanks for teaching me. 5.1.16 still fail on this machine. Please check the attachment. the strace output is too big though(73M as tgz), I could not attach it via email. Regards, - Chen
On Thursday, 21 July 2016 18:50:52 CEST Chen Hanxiao wrote:
At 2016-07-21 18:43:04, "Richard W.M. Jones" <rjones@redhat.com> 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? -- Pino Toscano
At 2016-07-21 19:52:11, "Pino Toscano" <ptoscano@redhat.com> wrote:
On Thursday, 21 July 2016 18:50:52 CEST Chen Hanxiao wrote:
At 2016-07-21 18:43:04, "Richard W.M. Jones" <rjones@redhat.com> 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?
Hi, Pino: 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? Regards, - Chen
On Thursday, 21 July 2016 20:04:05 CEST Chen Hanxiao wrote:
At 2016-07-21 19:52:11, "Pino Toscano" <ptoscano@redhat.com> wrote:
On Thursday, 21 July 2016 18:50:52 CEST Chen Hanxiao wrote:
At 2016-07-21 18:43:04, "Richard W.M. Jones" <rjones@redhat.com> 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?
Hi, Pino:
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?
supermin copies some needed modules in the initrd, and of course also the dependencies of these modules need to be copied as well. Copying a module without the needed modules for it means it won't even load. -- Pino Toscano
On Thu, Jul 21, 2016 at 08:04:05PM +0800, Chen Hanxiao wrote:
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?
modules.dep is used to work out the module dependencies, so we know which minimal set of modules should be copied into the initrd: https://github.com/libguestfs/supermin/blob/master/src/ext2_initrd.ml#L68-L1... If you copy too many modules into the initrd, then it will be huge and boot times will be very slow, so knowing the exact set of modules which are required is important. Of course if modules.dep is broken then that won't work. Do you understand who broke the file and/or why it was broken? 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
At 2016-07-21 21:17:07, "Richard W.M. Jones" <rjones@redhat.com> wrote:
On Thu, Jul 21, 2016 at 08:04:05PM +0800, Chen Hanxiao wrote:
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?
modules.dep is used to work out the module dependencies, so we know which minimal set of modules should be copied into the initrd:
https://github.com/libguestfs/supermin/blob/master/src/ext2_initrd.ml#L68-L1...
If you copy too many modules into the initrd, then it will be huge and boot times will be very slow, so knowing the exact set of modules which are required is important.
Of course if modules.dep is broken then that won't work.
Do you understand who broke the file and/or why it was broken?
Hi, Rich: Thanks for your kindly explanation. It looks like it's some guy's fat finger casuse this issue. I checked other machines installed the same centos version, it's all right. Regards, - Chen
participants (3)
-
Chen Hanxiao -
Pino Toscano -
Richard W.M. Jones