That the installation was ok all along, the kernel module is just not loaded at boot automatically (i.e. /etc/init.d/vboxdrv is not started).
So I ask again (I already did twice): What is the output of “chkconfig vboxdrv”?
It should say “vboxdrv on”.
If it says “off” (which is what I suspect now), you have to enable it, either with “sudo chkconf vboxdrv on”, “sudo systemctl enable vboxdrv”, or YaST->System->Services Manager.
Indeed, I now also think the installation was OK all along
sorry…
It does now (after I have taken the laptop home and rebooted it there)
I have actually done none of those things … I rather suspect that the error was a secondary consequence of something that happened in the lab this morning (not sure what, but the whole system seemed slow and unstable). Given that everything is fine now, at home, I will not be able to know what that was before it happens again.
In case I find the problem again, and further explanations of it, I will post them here.
For the time being, I am just very grateful for the extremely speedy and well-targeted support!
I had the same problem, so thanks for the fix.
In my case I’d installed VirtualBox a week or so ago, and then left it until today when it didn’t work immediately since I don’t use it much these days. I did have a problem after I first installed OpenSuse 13.2 and had to re-install it, but apart from that, I don’t remember any specific problems with the VirtualBox installation (other than that it didn’t immediately work!)
As well as manually loading vboxdrv, I had to load vboxnetadp and vboxnetflt to get the VM to run properly.
As well as these three (and the unrequired vbox guest), my updates directory contains vboxpci, voboxsf and vboxvideo, none of which show up with lsmod.
Should I load any of these as well?
You should not have to load any module manually.
Just enable the “vboxdrv” service as mentioned, either with “systemctl enable vboxdrv”, “chkconfig vboxdrv on” or YaST->System->Services Manager, and all necessary modules should be loaded at boot.
And you cannot load the guest modules (vboxpci, voboxsf and vboxvideo) on the host anyway.
I too have encountered this problem. In my case I had a pretty fresh clean installation of OpenSuse 13.2, I was in the process of building a collection of machines (guests), and virtualbox was working great for nearly a week, then yesterday afternoon I re-booted which lingered for a few minutes on a black screen before re-starting, and then I was unable to start my VBox machines.
Thanks wolfi323 for your contributions to this thread as I now have a solution, but unfortunately as Thailandian says “as well as manually loading vboxdrv, I had to load vboxnetadp and vboxnetflt to get the VM to run properly”, and despite enabling vboxdrv as advised by wolfi323 above (I did so using YaST->System->Services Manager), when the machine (host) is shut down there is as I said a lengthy wait (black screen), and when it is re-started vboxdrv is not enabled, and I have to load these three modules again to allow my vbox guests to work.
Here is the output for some of the commands previously mentioned in this thread;
michael@linux:~> su
Password:
linux:/home/michael # uname -a
Linux linux.site 3.16.7-21-desktop #1 SMP PREEMPT Tue Apr 14 07:11:37 UTC 2015 (93c1539) x86_64 x86_64 x86_64 GNU/Linux
linux:/home/michael # rpm -qa | egrep "kernel|virtualbox"
kernel-default-devel-3.16.7-21.1.x86_64
kernel-macros-3.16.7-21.1.noarch
virtualbox-guest-kmp-desktop-4.3.20_k3.16.7_21-13.1.x86_64
kernel-desktop-3.16.7-21.1.x86_64
kernel-source-3.16.7-21.1.noarch
virtualbox-qt-4.3.20-13.1.x86_64
kernel-xen-devel-3.16.7-21.1.x86_64
kernel-desktop-3.16.6-2.1.x86_64
kernel-desktop-devel-3.16.7-21.1.x86_64
virtualbox-host-kmp-desktop-4.3.20_k3.16.7_21-13.1.x86_64
kernel-syms-3.16.7-21.1.x86_64
virtualbox-4.3.20-13.1.x86_64
kernel-firmware-20141122git-5.1.noarch
kernel-devel-3.16.7-21.1.noarch
linux:/home/michael # systemctl status vboxdrv
vboxdrv.service - LSB: VirtualBox Linux module
Loaded: loaded (/etc/init.d/vboxdrv)
Active: inactive (dead)
Jul 03 08:02:43 linux.site systemd[1]: Dependency failed for LSB: VirtualBox Linux module.
linux:/home/michael # chkconfig vboxdrv
vboxdrv on
All help is greatly appreciated. Thanks
Michael
And what did you change? Something must cause this problem.
I have never seen anything like this and I’m using the openSUSE virtualbox packages since years.
Thanks wolfi323 for your contributions to this thread as I now have a solution, but unfortunately as Thailandian says “as well as manually loading vboxdrv, I had to load vboxnetadp and vboxnetflt to get the VM to run properly”, and despite enabling vboxdrv as advised by wolfi323 above (I did so using YaST->System->Services Manager), when the machine (host) is shut down there is as I said a lengthy wait (black screen), and when it is re-started vboxdrv is not enabled, and I have to load these three modules again to allow my vbox guests to work.
So you can load those 3 modules manually and then VirtualBox works?
What happens when you run “sudo systemctl vboxdrv start” or “sudo /etc/init.d/vboxdrv start” instead?
Does that work too?
Also please give the output of “sudo /etc/init.d/vboxdrv status” on a fresh boot, when VirtualBox doesn’t work.
This should give a more specific status message.
Actually I think this is your problem:
Jul 03 08:02:43 linux.site systemd[1]: Dependency failed for LSB: VirtualBox Linux module.
The dependencies for vboxdrv are this:
# Required-Start: $syslog $remote_fs
So, do you have a $syslog service installed? (rsyslog, syslog-ng, syslogd, or systemd-logger)
rpm -qa | grep log
Are you using any remote file systems (via NFS e.g.) that might fail to mount or have other problems? (remote file systems might also cause your hang at shutdown/reboot)
And just to be sure: you did not install the VirtualBox package from virtualbox.org at some point (or even have it installed), right?
rpm -qa | grep -i virtualbox
Thanks for your reply.
It seems you have hit the nail on the head, I removed the following line from /etc/fstab
//192.168.1.117/Backup /mnt/Backup cifs credentials=/etc/AWR_SAMBA 0 0
and re-booted to do “sudo /etc/init.d/vboxdrv status” on a fresh boot as you asked and the output is;
michael@linux:~> su
Password:
linux:/home/michael # /etc/init.d/vboxdrv status
VirtualBox kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) are loaded.
vboxdrv.service - LSB: VirtualBox Linux module
Loaded: loaded (/etc/init.d/vboxdrv)
Active: active (exited) since Fri 2015-07-03 15:37:55 BST; 3min 14s ago
Process: 929 ExecStart=/etc/init.d/vboxdrv start (code=exited, status=0/SUCCESS)
My cifs mount wasn’t working either so I’ll investigate that another time.
The virtualbox appears to function after re-boot now and there is no long wait to shut down.
Thanks
Michael
You may want to check that the Firewall is running and that samba is running
Thanks for this thread. I have the same problem. Read this and founded the solution.
For me it was a nfs-client defined in Yast to my nfs-/nas-server, that was not stated, and gave the problem.
Thanks
I had the same problem and could - somehow - solve it. The problem is, that the vbox-drivers are not loaded if any remote filesystem is in fstab and the network connection is a non-system-wide wifi. This doesn’t make much sense and it worked flawlessly in 13.1.
The (strange) solution is to make the wifi connection system-wide. This works as long as this actual wifi with the remote filesystem is accessible. If not, the drivers are not loaded and virtualbox isn’t starting although it doesn’t have any use for the remote filesystem.
Just to make sure: this is a clean install of 13.2., virtualbox is from the suse repos, oracle virtualbox has never been installed, wifi was added through networkmanager and the remote connection was added via Yast - so no hacking anywhere here and just how a regular user would and should do it.
So this is a clear bug, I guess somewhere hidden in systemd dependencies. So what to do about it?
Just in case:
phoenix:/lib/modules/3.16.7-29-desktop/updates # uname -a
Linux phoenix.olymp 3.16.7-29-desktop #1 SMP PREEMPT Fri Oct 23 00:46:04 UTC 2015 (6be6a97) x86_64 x86_64 x86_64 GNU/Linux
phoenix:/lib/modules/3.16.7-29-desktop/updates # rpm -qa | egrep -i "kernel|virtualbox"
virtualbox-qt-4.3.34-35.2.x86_64
virtualbox-host-kmp-desktop-4.3.34_k3.16.7_29-35.2.x86_64
kernel-desktop-3.16.7-29.1.x86_64
kernel-firmware-20141122git-5.1.noarch
virtualbox-4.3.34-35.2.x86_64
phoenix:/lib/modules/3.16.7-29-desktop/updates # /etc/init.d/vboxdrv setup
Recompiling VirtualBox kernel module, NOT. It has been packaged. done
phoenix:/lib/modules/3.16.7-29-desktop/updates # systemctl status vboxdrv
vboxdrv.service - LSB: VirtualBox Linux module
Loaded: loaded (/etc/init.d/vboxdrv)
Active: inactive (dead)
Jan 11 19:11:01 phoenix.olymp systemd[1]: **Dependency failed for LSB: VirtualBox Linux module. **
phoenix:/lib/modules/3.16.7-29-desktop/updates # chkconfig vboxdrv
vboxdrv on
phoenix:/lib/modules/3.16.7-29-desktop/updates # /sbin/modprobe -v vboxdrv
insmod /lib/modules/3.16.7-29-desktop/updates/vboxdrv.ko
phoenix:/lib/modules/3.16.7-29-desktop/updates # dmesg|tail
1628.099724] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=33:33:00:00:00:fb:18:34:51:e9:d7:c4:86:dd SRC=fe80:0000:0000:0000:1c53:d35b:1c6e:2289 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=256 TC=0 HOPLIMIT=255 FLOWLBL=3382 PROTO=UDP SPT=5353 DPT=5353 LEN=216
1628.301077] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=33:33:00:00:00:fb:18:34:51:e9:d7:c4:86:dd SRC=fe80:0000:0000:0000:1c53:d35b:1c6e:2289 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=552 TC=0 HOPLIMIT=255 FLOWLBL=3382 PROTO=UDP SPT=5353 DPT=5353 LEN=512
1629.324750] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=33:33:00:00:00:fb:18:34:51:e9:d7:c4:86:dd SRC=fe80:0000:0000:0000:1c53:d35b:1c6e:2289 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=552 TC=0 HOPLIMIT=255 FLOWLBL=3382 PROTO=UDP SPT=5353 DPT=5353 LEN=512
1656.960690] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=33:33:00:00:00:fb:64:b9:e8:41:45:6a:86:dd SRC=fe80:0000:0000:0000:66b9:e8ff:fe41:456a DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=121 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=81
1672.007959] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=33:33:00:00:00:fb:64:b9:e8:41:45:6a:86:dd SRC=fe80:0000:0000:0000:66b9:e8ff:fe41:456a DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=468 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=428
1687.975655] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=33:33:00:00:00:fb:64:b9:e8:41:45:6a:86:dd SRC=fe80:0000:0000:0000:66b9:e8ff:fe41:456a DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=142 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=102
2037.238198] vboxdrv: Found 4 processor cores.
2037.240224] vboxdrv: fAsync=0 offMin=0x2ee offMax=0x2475
2037.240421] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
2037.240426] vboxdrv: Successfully loaded version 4.3.34_SUSE (interface 0x001a000b).
phoenix:/lib/modules/3.16.7-29-desktop/updates # ls -l /lib/modules/3.16.7-29-desktop/updates
total 644
-rw-r--r-- 1 root root 555674 Nov 16 11:51 vboxdrv.ko
-rw-r--r-- 1 root root 16018 Nov 16 11:51 vboxnetadp.ko
-rw-r--r-- 1 root root 44994 Nov 16 11:51 vboxnetflt.ko
-rw-r--r-- 1 root root 39266 Nov 16 11:51 vboxpci.ko
Going back to the first posts of this thread, it looked like a permissions issue, so perhaps the user was not included in the vboxusers group, which AFAIK is necessary to run vbox as a normal user, at least in oS 13.2
True, that’s necessary, but if that’s not the case a dialog should pop up informing you about the specific issue.
It’s also true though that openSUSE’s vboxdrv init script (and also vboxadd for the guest additions) requires $remote_fs, and won’t start if you e.g. have nfs mounts in your fstab that fail to be mounted.
That was a deliberate choice/change of the then (open)SUSE package maintainer years ago, because /usr might reside on a network share.
If you think that’s a bug, please report it at http://bugzilla.opensuse.org/ (same username/password as here)
No, I just thought it could be the problem.
At least here (oS 13.2 KDE) if I remove myself from the group I get the warning if I try to run Virtualbox, but if I try a previously working shortcut to a VM I just get a dialog box saying “KDEInit couldn’t start ‘/usr/lib/virtualbox/VirtualBox’”.
But I do think the warning is more than enough, so it’s not a bug AFAICT.
I continue to experience a similar issue, though have no remote file systems in /etc/fstab.
I’ve not recently updated from 13.1 to 13.2, though VB suddenly just stopped working for me.
I’m having to manually load the kernel modules after reboot.
I’ve reinstalled all kernel packages and virtualbox packages, but issue persists.
Does anyone have any further suggestions?
calculus:~ # /etc/init.d/vboxdrv status
VirtualBox kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) are loaded.
vboxdrv.service - LSB: VirtualBox Linux module
Loaded: loaded (/etc/init.d/vboxdrv)
Active: active (exited) since Wed 2016-01-13 08:45:03 EST; 4min 7s ago
Process: 3721 ExecStart=/etc/init.d/vboxdrv start (code=exited, status=0/SUCCESS)
calculus:~ # rpm -qa | grep -i virtualbox
virtualbox-guest-kmp-default-4.3.34_k3.16.7_29-35.2.x86_64
virtualbox-host-kmp-desktop-4.3.34_k3.16.7_29-35.2.x86_64
virtualbox-host-kmp-default-4.3.34_k3.16.7_29-35.2.x86_64
virtualbox-qt-4.3.34-35.2.x86_64
virtualbox-guest-kmp-desktop-4.3.34_k3.16.7_29-35.2.x86_64
virtualbox-4.3.34-35.2.x86_64
calculus:~ # uname -a
Linux calculus.site 3.16.7-29-desktop #1 SMP PREEMPT Fri Oct 23 00:46:04 UTC 2015 (6be6a97) x86_64 x86_64 x86_64 GNU/Linux
calculus:~ # lsmod | grep vbox
vboxpci 27323 0
vboxnetflt 31926 0
vboxnetadp 25670 0
vboxdrv 434892 3 vboxnetadp,vboxnetflt,vboxpci
The original problem in this thread was that vboxdrv.service wasn’t started on boot.
At least here (oS 13.2 KDE) if I remove myself from the group I get the warning if I try to run Virtualbox, but if I try a previously working shortcut to a VM I just get a dialog box saying “KDEInit couldn’t start ‘/usr/lib/virtualbox/VirtualBox’”.
Well, /usr/lib/virtualbox/VirtualBox can only be accessed by users of the group “vboxusers” (and root).
That’s one of the reasons why you need to be a member of that group to use VirtualBox.
It’s the start script that shows the warning (/usr/bin/VirtualBox), but your shortcut runs /usr/lib/virtualbox/VirtualBox directly, so the warning doesn’t appear.
I wouldn’t see this as bug though because you have to run VirtualBox first (and you can only do that if you are member of the group) to actually create that shortcut.
But I do think the warning is more than enough, so it’s not a bug AFAICT.
I was talking about the dependency on $remote_fs, i.e. that virtualbox’s services (vboxdrv in particualar) fail to start when a remote filesystem cannot be mounted.
And what does that mean exactly? Do you get an error message?
calculus:~ # /etc/init.d/vboxdrv status
VirtualBox kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) are loaded.
vboxdrv.service - LSB: VirtualBox Linux module
Loaded: loaded (/etc/init.d/vboxdrv)
Active: active (exited) since Wed 2016-01-13 08:45:03 EST; 4min 7s ago
Process: 3721 ExecStart=/etc/init.d/vboxdrv start (code=exited, status=0/SUCCESS)
calculus:~ # rpm -qa | grep -i virtualbox
virtualbox-guest-kmp-default-4.3.34_k3.16.7_29-35.2.x86_64
virtualbox-host-kmp-desktop-4.3.34_k3.16.7_29-35.2.x86_64
virtualbox-host-kmp-default-4.3.34_k3.16.7_29-35.2.x86_64
virtualbox-qt-4.3.34-35.2.x86_64
virtualbox-guest-kmp-desktop-4.3.34_k3.16.7_29-35.2.x86_64
virtualbox-4.3.34-35.2.x86_64
calculus:~ # uname -a
Linux calculus.site 3.16.7-29-desktop #1 SMP PREEMPT Fri Oct 23 00:46:04 UTC 2015 (6be6a97) x86_64 x86_64 x86_64 GNU/Linux
calculus:~ # lsmod | grep vbox
vboxpci 27323 0
vboxnetflt 31926 0
vboxnetadp 25670 0
vboxdrv 434892 3 vboxnetadp,vboxnetflt,vboxpci
Well, this is after you manually loaded the kernel modules, right?
What’s the output (from the first command in particular) before you do that, i.e. when VirtualBox does not work?
Oh and you could uninstall virtualbox-host-kmp-default (and also kernel-default if it is installed), as you are using kernel-desktop anyway.
/etc/init.d/vboxdrv depends on two services: $syslog $remote_fs
As you say you don’t have a remote filesystem in your fstab, what syslog daemon are you using? Maybe that failed to start?
systemctl status syslog
Do you have systemd-logger installed?
And is vboxdrv actually enabled to start during boot?
chkconfig vboxdrv
PS, actually there already is a bug report about that problem:
https://bugzilla.opensuse.org/show_bug.cgi?id=908383