virtualbox-dkms installation hangs in 18.04 (with secure boot)

After killing the hung apt process I ran dpkg --configure -a , which hung again. Killing the hung dpkg process and running dpkg --configure -a again allowed the package installation to complete but resulted in a broken module:

$ VirtualBox
WARNING: The character device /dev/vboxdrv does not exist.
  Please install the virtualbox-dkms package and the appropriate
  headers, most likely linux-headers-generic.

  You will not be able to start VMs until this problem is fixed.
$

FWIW:

$ apt-cache policy linux-headers-generic
linux-headers-generic:
  Installed: 4.15.0.22.23
  Candidate: 4.15.0.22.23
  Version table:
 *** 4.15.0.22.23 500
        500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     4.15.0.20.23 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
$

After working on this a bit more, this problem is probably caused by Secure Boot being enabled on my dual-boot (w/ windows 10) system.

https://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur

I am having the same problem. Ubuntu 18.04 installed with Windows 10 as dual boot. Secure boot enabled. The system has been working for years like this (since before 16.04). I have updated to every release since and it was working on all of them. It even worked on 18.04 before the latest kernel update. I suspect a work around could be to downgrade to a previous kernel or to disable module signing, but we should not have to.

 I sign my own modules with the following:

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

After every kernel upgrade I sign the modules with:
#!/bin/bash

for f in $(dirname $(modinfo -n vboxdrv))/*.ko; do echo "Signing $f"; sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $f; done
modprobe vboxdrv

The kernel upgrade to 4.15.0-22 broke this process. Now the install of virtual box will stall on the following:
Building initial module for 4.15.0-22-generic

My workaround was to set up the upstream VirtualBox PPA and install the packages from there:

https://www.virtualbox.org/wiki/Linux_Downloads

Then maunally sign them.

Status changed to 'Confirmed' because the bug affects multiple users.

The problem is that the DKMS hook in virtualbox-dkms starts a whiptail dialog explaining that a new signing key will be enrolled in the MOK database, but this dialog does not get displayed, which is why the system appears to hang.

Below is the output of 'pstree' showing the stack of commands and the whiptail content.

Secondary issue (with DKMS): I have a signing key in the MOK database already (like commenter #4), with which I have always used signed the vbox drivers, so I do not want to enrol a _new_ signing key. So even if I would see the dialog, it does not present the appropriate option.

I have tried this with aptitude, apt, dpkg --configure, both inside and outside of a 'screen' session (to make sure I was on a plain console), but the dialog does not show up in any of these cases.

This is the pstree output:

└─aptitude,5796
   ├─sh,11827 -c DPKG_NO_TSTP=1 dpkg --configure -a
   └─dpkg,11828 --configure -a
       └─virtualbox-dkms,11829 /var/lib/dpkg/info/virtualbox-dkms.postinst configure 5.2.10-dfsg-6ubuntu18.04.1
          └─common.postinst,11830 /usr/lib/dkms/common.postinst virtualbox 5.2.10 /usr/share/virtualbox-dkms 5.2.10-dfsg-6ubuntu18.04.1
             └─dkms,12103 /usr/sbin/dkms build -m virtualbox -v 5.2.10 -k 4.15.0-24-generic
                └─dkms,12120 /usr/sbin/dkms build -m virtualbox -v 5.2.10 -k 4.15.0-24-generic
                   └─frontend,15868 -w /usr/share/debconf/frontend /usr/sbin/update-secureboot-policy --enroll-key
                      ├─update-securebo,15882 /usr/sbin/update-secureboot-policy --enroll-key
                      └─whiptail,15897 --backtitle Package configuration --title Configuring Secure Boot --output-fd 12 --nocancel --msgbox Y our system has UEFI Secure Boot enabled.\012\012UEFI Secure Boot requires additional configuration to work with third-party drivers.\012\012The system will assist you in configuring UEFI Secure Boot. To permit the use of third-party drivers, a new Machine-Owner Key (MOK) has been generated. This key now needs to be enrolled in your system's \012firmware.\012\012To ensure that this change is being made by you as an authorized user, and not by an attacker, you must choose a password now and then confirm the change after reboot using the same password, in both the\012"Enroll MOK" and "Change Secure Boot state" menus that will be presented to you when this system reboots.\012\012If you proceed but do not confirm the password upon reboot, Ubuntu will still be able to boot on your system but any hardware that requires third-party drivers to work correctly may not be usable. 17 208

Using ...

sudo apt install --reinstall virtualbox-dkms

... I have the same issue as user zwets above in this message thread:

whiptail command hangs infinitely and does not show a menu possibly because of the bad environment it is running in.

My workaround was to kill the perl process and run it standalone ...

sudo perl -w /usr/share/debconf/frontend /usr/sbin/update-secureboot-policy --enroll-key

... in a usual interactive shell, so that whiptail shows the menu to set a password.

Afterwards (that is, after reboot and enrolling this password key during boot) VirtualBox is running for me on Ubuntu 18.04 with secure boot and does not complain about an unsigned vboxdrv anymore.

Seems to be a design flaw to prevent interactivity during installation.

My current workaround is to remove the redirection of /usr/lib/dkms/dkms_autoinstaller's stdout to /dev/null in /etc/kernel/header_postinst.d/dkms. This may even be the correct fix: it's a little noisier, but not unacceptably so and it's definitely better than a hung installation.

The same problem with redirection to /dev/null seems also to be present in /usr/lib/dkms/common.postinst, causing hangs on upgrades...

I'm suffering with this again. Is the work around really to turn off boot protection?

I've struggled through this several times now. I don't have a definitive solution but the general routine was something like this. When you asked to enroll the machine owner key to sign the kernel module there is an interface that popups up and waits for user input. I tried this in in a shell-only session and in a gnome session several times. In both cases the process that spawns the window gets stuck in a child process and I think it was sent to a different tty altogether. One time I accidentally recover the interface by killing all the login window session processes while I was in a trying something else in a shell session. When i jumped back everything redrew and there was a new window that asked me to enroll the MOK key password.

I was not able to reproduce that the next time I got stuck in this spot, but what worked for me was disabling my machines nvidia video card proprietary drivers, and then switching from wayland to gnome (or gnome to wayland) after I did that then the processes worked as it was supposed to.

This issue is very frustrating, but you should be able to keep secure boot enabled. I saved the logs from those times I was able to get it to work. I'll see if I can find anything to back up what I'm saying here.