#12262 closed defect (fixed)
vboxautostart-service is not executed correctly on startup in Debian
回報者: | _Thomas_ | 負責人: | |
---|---|---|---|
元件: | host support | 版本: | VirtualBox 4.3.0 |
關鍵字: | 副本: | ||
Guest type: | all | Host type: | Linux |
描述 (由 作最後更新)
Somehow the startup script in the Debian dist does not auto start configured auto start engines. To fix this it is necessary to tweak the vboxautostart-service script not to exit when the modules are not detected. I don't know why but somehow the checking of loaded modules fails, probably it is because of some background startup. However the modules are loaded after start and also auto startup works when simply disabled the checking. Of course it breaks handling of real problems.
Please see following discussion for some users haveing this issue: https://forums.virtualbox.org/viewtopic.php?f=11&t=51529
*** vboxautostart-service.orig 2013-10-26 22:28:25.000000000 +0200 --- vboxautostart-service 2013-10-26 22:09:13.000000000 +0200 *************** start() { *** 271,277 **** begin_msg "Starting VirtualBox VMs configured for autostart"; vboxdrvrunning || { fail_msg "VirtualBox kernel module not loaded!" ! exit 0 } PARAMS="--background --start --config $VBOXAUTOSTART_CONFIG" --- 271,277 ---- begin_msg "Starting VirtualBox VMs configured for autostart"; vboxdrvrunning || { fail_msg "VirtualBox kernel module not loaded!" ! ## exit 0 } PARAMS="--background --start --config $VBOXAUTOSTART_CONFIG"
更動歷史 (6)
comment:3 11 年 前 由 編輯
Hi,
I had the same problem on a ubuntu server 12.04. I do think that the proble is that in rc2.d vboxdrv is scheduled to start with the same priority as vboxautostart-service. Since init scripts with same priority are launched in alphabetical order it happens that vboxautostart-service is started before vboxdrv. This causes the the check to fail.
I fixed this updating runlevels using update-rc. You have to remove all links from runlevels and then repudate xboxdrv to start with proprity 19 (since vboxautostart-service starts with priority 20):
root@host:/etc/# update-rc.d -f vboxdrv remove root@host:/etc/# update-rc.d -f vboxdrv defaults 19
You should fix your deb package to schedule vboxdrv with the right priority.
Hope to be usefull and to be in the right place.
Thanks for the great work.
comment:4 11 年 前 由 編輯
I've encountered the similar problem on Ubuntu 12.04 LTS. The solution proposed by atixk works for auto-start, but it doesn't work for auto-shutdown - on auto-shutdown, e.g. when host is going to reboot, vboxdrv stop
hangs and blocks shutdown of the host. The problem seems to be that if there is an host-only interface configured, host system is unable to do rmmod vboxnetadp
(host hangs) on reboot or poweroff of the host.
In dmesg
one can see:
unregister_netdevice: waiting for vboxnet0 to become free. Usage count = 1
The solution that works for me:
sudo update-rc.d -f vboxdrv remove sudo update-rc.d vboxdrv defaults 19 21
Basically: vboxdrv
has to be started before vboxautostart-service
and it has to be stopped after vboxautostart-service
.
Another problem is that if I connect to guest using SSH (guest OS is also Ubuntu 12.04 LTS, guest has two interfaces configured: a bridged and a host-only interface, ssh connection uses the bridged interface), guest receives ACPI shutdown signal, SSH client informs that connection is lost, but host is unable to reboot - it again hangs trying to unload vboxnetadp. In processes running on host I can see that VBoxHeadless
didn't exit. Killing it makes possible to unload the module.
For this I've applied a workaround: in vboxautostart-service
in function stop()
I've added sleep 3
just before return $RETVAL
. This seems to resolve the problem.
Details of virtualbox-4.3
package:
apt-cache show virtualbox-4.3 Package: virtualbox-4.3 Version: 4.3.10-93012~Ubuntu~precise (...) Filename: pool/contrib/v/virtualbox-4.3/virtualbox-4.3_4.3.10-93012~Ubuntu~precise_amd64.deb (...)
comment:5 11 年 前 由 編輯
Thanks for the report and the findings. Actually this was a misunderstanding. The installer thinks that update-rc.d will always scan the 'Required-Start' fields of the startup scripts. This is not always the case. The universal installer does this already correct, the postinst Debian script didn't. Fixed in r51040. The fix will be part of the next 4.3.x maintenance release. I'm not sure if updating the package will help to fix the boot priority, a uninstall + re-install might be necessary.
Which Debian version is this?