* Michael Tokarev:
> Do you want us to depend on kmod, or do you think we should check
> modprobe presence in initscript instead, and omit module loading
> if modprobe isn't found?
I just retried after installing kmod (but no kernel) to the chroot.
Setting up qemu-system-x86 (1.5.0+dfsg-2) ...
update-alternatives: using /usr/bin/qemu-system-i386 to provide /usr/bin/qemu
(qemu) in auto mode
libkmod: ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open
moddep file '/lib/modules/3.8-1-amd64/modules.dep.bin'
Module kvm_amd failed to load ... failed!
invoke-rc.d: initscript qemu-system-x86, action "start" failed.
dpkg: error processing qemu-system-x86 (--configure):
subprocess installed post-installation script returned error exit status 1
I don't quite see what benefits exiting from the init script with exit
code 1 has. Changing that to
log_failure_msg "Module $module failed to load"
exit 0
would still produce the error message and allow the package to be
configured.
The bug may not be as severe as I originally thought: Apparently, I had
set up my sid-i386 chroot differently from the sid-amd64 chroot (on
which everything builds just fine): My sid-i386 chroot lacked a
/usr/sbin/policy-rc.d script that prevents init scripts from being run.
I think that it would still be a good idea if this issue was fixed. One
wouldn't want the package installation to fail if the user uses his own
kernel without KVM support. After all, qemu-system still has support for
TCG, doesn't it?
Cheers,
-Hilko
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
