How can I setup VirtualBox properly in 17.04?

Question

I was installing VirtualBox from the main site, with the .dpkg package given, and during the installation I got the error:

dpkg: dependency problems prevent configuration of virtualbox-5.1:
 virtualbox-5.1 depends on libqt5x11extras5 (>= 5.6.0); however:
  Package libqt5x11extras5 is not installed.
 virtualbox-5.1 depends on libsdl1.2debian (>= 1.2.11); however:
  Package libsdl1.2debian is not installed.

dpkg: error processing package virtualbox-5.1 (--install):
 dependency problems - leaving unconfigured
Processing triggers for systemd (232-21ubuntu5) ...
Processing triggers for ureadahead (0.100.0-19) ...
ureadahead will be reprofiled on next reboot
Processing triggers for bamfdaemon (0.5.3+17.04.20170406-0ubuntu1) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for gnome-menus (3.13.3-6ubuntu5) ...
Processing triggers for desktop-file-utils (0.23-1ubuntu2) ...
Processing triggers for mime-support (3.60ubuntu1) ...
Processing triggers for hicolor-icon-theme (0.15-1) ...
Processing triggers for shared-mime-info (1.8-1) ...
Errors were encountered while processing:
 virtualbox-5.1

At fist a thought the problem was about unmet dependencies and ran:

sudo apt-get install -f

But then I got the following error message:

Adding group `vboxusers' (GID 132) ...
Done.
Created symlink /etc/systemd/system/multi-user.target.wants/vboxdrv.service → /lib/systemd/system/vboxdrv.service.
Created symlink /etc/systemd/system/multi-user.target.wants/vboxballoonctrl-service.service → /lib/systemd/system/vboxballoonctrl-service.service.
Created symlink /etc/systemd/system/multi-user.target.wants/vboxautostart-service.service → /lib/systemd/system/vboxautostart-service.service.
Created symlink /etc/systemd/system/multi-user.target.wants/vboxweb-service.service → /lib/systemd/system/vboxweb-service.service.
vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.

There were problems setting up VirtualBox.  To re-start the set-up process, run
  /sbin/vboxconfig
as root.

After this I ran the command suggested and got exactly the same error.

As suggested for @George I ran dmesg -kHd --time-format ctime | tail -20 , the resulting lines were:

[dom ago 13 13:59:07 2017 <    0,005021>] wlo1: authenticate with ea:de:27:93:b1:50
[dom ago 13 13:59:07 2017 <    0,005558>] wlo1: send auth to ea:de:27:93:b1:50 (try 1/3)
[dom ago 13 13:59:07 2017 <    0,003337>] wlo1: authenticated
[dom ago 13 13:59:07 2017 <    0,008390>] wlo1: associate with ea:de:27:93:b1:50 (try 1/3)
[dom ago 13 13:59:07 2017 <    0,006367>] wlo1: RX AssocResp from ea:de:27:93:b1:50 (capab=0x421 status=0 aid=1)
[dom ago 13 13:59:07 2017 <    0,001071>] wlo1: associated
[dom ago 13 14:01:06 2017 <  119,551821>] wlo1: disconnect from AP ea:de:27:93:b1:50 for new auth to c6:6e:1f:08:83:ce
[dom ago 13 14:01:06 2017 <    0,005411>] wlo1: authenticate with c6:6e:1f:08:83:ce
[dom ago 13 14:01:06 2017 <    0,004158>] wlo1: send auth to c6:6e:1f:08:83:ce (try 1/3)
[dom ago 13 14:01:06 2017 <    0,005006>] wlo1: authenticated
[dom ago 13 14:01:06 2017 <    0,001436>] wlo1: associate with c6:6e:1f:08:83:ce (try 1/3)
[dom ago 13 14:01:06 2017 <    0,003535>] wlo1: RX AssocResp from c6:6e:1f:08:83:ce (capab=0x421 status=0 aid=1)
[dom ago 13 14:01:06 2017 <    0,000535>] wlo1: associated
[dom ago 13 14:05:07 2017 <  240,406581>] wlo1: disconnect from AP c6:6e:1f:08:83:ce for new auth to c6:6e:1f:08:83:cf
[dom ago 13 14:05:07 2017 <    0,014262>] wlo1: authenticate with c6:6e:1f:08:83:cf
[dom ago 13 14:05:07 2017 <    0,006950>] wlo1: send auth to c6:6e:1f:08:83:cf (try 1/3)
[dom ago 13 14:05:07 2017 <    0,002182>] wlo1: authenticated
[dom ago 13 14:05:07 2017 <    0,005477>] wlo1: associate with c6:6e:1f:08:83:cf (try 1/3)
[dom ago 13 14:05:07 2017 <    0,001717>] wlo1: RX AssocResp from c6:6e:1f:08:83:cf (capab=0x1 status=0 aid=1)
[dom ago 13 14:05:07 2017 <    0,001518>] wlo1: associated

What can I do to fix this?

Answer 1

I was able to resolve the problem thanks to the comments, and I'm sharing the solution in case somenone runs into the same problem as I did. The UEFI, interface between your hardware and software, which is the most responsible for the boot of your system, has a technology called Secure Boot, which in turn checks if the system boot loader is signed with a cryptographic key authorized by a database contained in the firmware. With adequate signature verification in the next-stage boot loader(s), kernel, and, potentially, user space, it is possible to prevent the execution of unsigned code. This helps with the security of your system and difficult the access of malicious software to your system.

The current problem thrown in the installation is due to the lack of a valid key for some modules of the software VirtualBox. If you have this problem, there are a couple of ways in which you can handle it, the first is easy and the last one is a bit effortful:

1. Disable SECURE BOOT as pointed by Pilot6:

In most cases you can get into UEFI settings using grub menu. Press ESC button on booting, get into grub menu and select System Setup. Secure Boot option should be in "Security" or "Boot" section of the UEFI.

You can get into UEFI directly, but it depends on your hardware. Read your computer manual to see how to get there. It may be Del, or F2 on boot, or something else.

An alternative way is to disable Secure Boot using mokutil.

Since Ubuntu kernel build 4.4.0-21.37 this can be fixed by running

sudo apt install mokutil
sudo mokutil --disable-validation

It will require to create a password. The password should be at least 8 characters long. After you reboot, UEFI will ask if you want to change security settings. Choose "Yes".

Then you will be asked to enter the previously created password. Some UEFI firmware asks not for the full password, but to enter some characters of it, like 1st, 3rd, etc. Be careful. Some people do not understand this. I did not get it from the first attempt either ;-)

Update: Now this kernel config is enabled in all supported Ubuntu kernels. Ubuntu 16.04, 15.10 and 14.04 are affected.

2. Sing VituralBox modules as suggested by Majal:

Since kernel version 4.4.0-20, it was enforced that unsigned kernel modules will not be allowed to run with Secure Boot enabled. Because you want to keep Secure Boot, then the next logical step is to sign those modules.

So let's try it.

1. Create signing keys

   openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"
   

2. Sign the module (vboxdrv for this example)

   sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vboxdrv)
   

3. Register the keys to Secure Boot

   sudo mokutil --import MOK.der
   

   Supply a password for later use after reboot

4. Reboot and follow instructions to Enroll MOK (Machine Owner Key). Here's a sample with pictures. The system will reboot one more time. After the reboot, you may also need to sudo modprobe vboxdrv to load the module.

Please let me know if VirtualBox would run this way on Ubuntu 16.04 (on kernel 4.4.0-21 or higher, I believe).

Resources: Detailed website article for Fedora and Ubuntu implementation of module signing. (they've been working on it) ;-) And for the security conscious, please consider the comment of @zwets below. To have full network and PCI capabilities, you may wish to sign the following modules as well: vboxnetflt, vboxnetadp, and vboxpci. Thanks to @shasha_trn for the comment below.

Additional resource: I created a bash script for my own use every time virtualbox-dkms upgrades and thus overwrites the signed modules. Check out my vboxsign on GitHub.