TL;DR Getting vagrant + virtualbox running natively in Bash for Unbuntu on Windows is a no-go. Try a hybrid Windows/WSL solution instead.
At the end of our last episode, our hero was trapped under the following paradox:
mike@MIKE-WIN10-SSD:/mnt/c/Users/Mike/VirtualBox VMs/BaseDebianServer$ vagrant up VirtualBox is complaining that the installation is incomplete. Please run `VBoxManage --version` to see the error message which should contain instructions on how to fix this error. mike@MIKE-WIN10-SSD:/mnt/c/Users/Mike/VirtualBox VMs/BaseDebianServer$ VBoxManage --version WARNING: The character device /dev/vboxdrv does not exist. Please install the virtualbox-dkms package and the appropriate headers, most likely linux-headers-3.4.0+. You will not be able to start VMs until this problem is fixed.
However, the advice for installing virtualbox-dkms is merely a distraction:
mike@MIKE-WIN10-SSD:/mnt/c/Users/Mike/VirtualBox VMs/BaseDebianServer$ sudo apt-get install virtualbox-dkms Reading package lists... Done Building dependency tree Reading state information... Done virtualbox-dkms is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 44 not upgraded.
And installing linux-headers-3.4.0+ doesn’t seem to work:
mike@MIKE-WIN10-SSD:/mnt/c/Users/Mike/VirtualBox VMs/BaseDebianServer$ sudo apt-get install linux-headers-3.4.0+ Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package linux-headers-3.4.0 E: Couldn't find any package by regex 'linux-headers-3.4.0'
Where to go from here?
AskUbuntu turns up this tasty lead:
…where VBoxManage instead indicates “…most likely linux-headers-generic”. This aligns with my previous investigation into the version of Linux that ships with Bash on Ubuntu for Windows (‘uname -r’ returns “3.4.0+”, which I suspect is what VBoxManage appends to its “most likely” hint).
On a lark, I decided to see if I could confirm this theory from the virtualbox source code. Since it’s Oracle, of course they had to use an “enterprise-y” repo (Trac) which provides a browseable but not searchable front-end, so I pawed through each of the .cpp files by hand on the off-chance this message was being constructed directly in VBoxManage*.cpp source:
It’s entirely possible the message is passed up from an imported library, or that it’s constructed from fragments that don’t explicitly include the string “most likely” in any one line of source, but I wasn’t able to find it from this branch of the virtualbox source repo.
Dead End, Take a Guess
OK, if there’s no specific indication which version of the headers must be used, and on the assumption no damage can be caused by downloading what should merely be text files, then let’s just try the linux-headers-generic and see what happens.
And the apt-get messages seem promising – especially that it selected linux-headers-3.13.* files magically without me tracking down which specific versions I needed:
mike@MIKE-WIN10-SSD:/mnt/c/Users/Mike/VirtualBox VMs/BaseDebianServer$ sudo apt-get install linux-headers-generic [sudo] password for mike: Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: linux-headers-3.13.0-92 linux-headers-3.13.0-92-generic The following NEW packages will be installed: linux-headers-3.13.0-92 linux-headers-3.13.0-92-generic linux-headers-generic 0 upgraded, 3 newly installed, 0 to remove and 44 not upgraded. Need to get 9,571 kB of archives. After this operation, 77.0 MB of additional disk space will be used. Do you want to continue? [Y/n]
Cool, except for these lines in the script output:
Examining /etc/kernel/header_postinst.d. run-parts: executing /etc/kernel/header_postinst.d/dkms 3.13.0-92-generic /boot/vmlinuz-3.13.0-92-generic
(why does that make me think I just overwrote something important?)
…and for reasons initially unknown to me, the run-parts script seems to go zombie.
[Aside: I’m still too polluted by my Win32 experience, so I kept trying to interrupt with Ctrl-C. No. Bad dog, no treat. Instead, try Ctrl-Z (pronounced “zed”, ’cause I’m Canadian like that.]
Finding Out if Anyone Else Has Seen This
Vagrant is a pretty popular way of managing virtual machines these days, right? Yeah. And while I might be in the first days of the public release of Bash on Windows, there’s been an Insiders Preview going for months, and lots of people banging on the corners.
So what are the odds someone else has tried this too?
=== NOW HERE’S THE PART THAT BLEW MY MIND ===
A Microsoft employee responded with an intelligent and helpful reply within hours on the same day!!!
(I remember a decade ago, Microsoft’s ‘engagement’ with customers reporting real issues with new software – even when Microsoft’s external bug trackers existed – was abysmal. You’d be lucky to get an acknowledgement inside a month, and rarely if ever would they bother to update the issue when/if it ever got dispositioned, let alone addressed. THIS KIND OF RESPONSIVENESS IS AMAZING FROM A CORPORATION.)
My bad, I’d misunderstood the implications of this: WSL (Windows Subsystem for Linux), which supports the user-mode Bash on Ubuntu layer, doesn’t implement any native Linux kernel support. It’s all user-mode support, and it’s only for non-GUI apps (i.e. things that don’t require Display:0).
Our intrepid Microsoft employee reports here that DKMS isn’t currently supported. The fact I took it even further to try installing the linux headers was moot; /dev/vboxdrv wouldn’t be available no matter what.
Cleanup in Aisle 4
Did you happen to go down the same road as me? [What, are you similarly touched in the head?] If so, here’s what I did to back out of my mess:
- Performed the lock/install package cleanup specified here
- Did as clean an uninstall of the linux-headers-generic package as I could (running sudo apt-get –purge remove linux-headers-generic), which outputs
Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-generic* 0 upgraded, 0 newly installed, 1 to remove and 47 not upgraded. 2 not fully installed or removed. After this operation, 29.7 kB disk space will be freed. Do you want to continue? [Y/n]
…which leads to the same run-parts script that fails. Cleanup the locks/install packages again…then pray not enough damage was done by run-parts (in either direction) to matter. [Boy is that a landmine waiting to go off months from now…]
- Clean uninstall of vagrant (sudo apt-get –purge remove vagrant)…which somehow leads again to these same lines:
... Do you want to continue? [Y/n] (Reading database ... 64370 files and directories currently installed.) Removing vagrant (1.4.3-1) ... Purging configuration files for vagrant (1.4.3-1) ... Processing triggers for man-db (188.8.131.52-1ubuntu1) ... Setting up linux-headers-3.13.0-92-generic (3.13.0-92.139) ... Examining /etc/kernel/header_postinst.d. run-parts: executing /etc/kernel/header_postinst.d/dkms 3.13.0-92-generic /boot/vmlinuz-3.13.0-92-generic
Ctrl-Z, rm locks and install bits. [This is getting old.]
- Clean uninstall of virtualbox (sudo apt-get –purge remove virtualbox)…and once again that unkillable linux-headers setup rears its head.
- Let’s look closer.
- Here’s the preamble when removing the vagrant package:
mike@MIKE-WIN10-SSD:/var/lib/dpkg/updates$ sudo apt-get --purge remove vagrant Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: bsdtar libarchive13 liblzo2-2 libnettle4 libruby1.9.1 ruby ruby-childprocess ruby-erubis ruby-ffi ruby-i18n ruby-log4r ruby-net-scp ruby-net-ssh ruby1.9.1 Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: vagrant* 0 upgraded, 0 newly installed, 1 to remove and 47 not upgraded. 1 not fully installed or removed. After this operation, 1,612 kB disk space will be freed. Do you want to continue? [Y/n]
[My italics for emphasis]
- Maybe – just MAYBE – the “not fully installed” package is linux-headers-generic, and if I could coax apt-get or dpkg to clean *that* up, we’d rid ourselves of this mess. [*foreshadowing* …or maybe I just need to find out how to wipe and reinstantiate Bash on Windows…]
- First, do the suggested cleanup (sudo apt-get autoremove)
- Then install debfoster and deborphan
- Debfoster reports nothing interesting, but deborphan reports:
deborphan: The status file is in an improper state. One or more packages are marked as half-installed, half-configured, unpacked, triggers-awaited or triggers-pending. Exiting.
- This article provides a great grep for isolating the issue – here’s what it uncovered:
Package: linux-headers-3.13.0-92-generic Status: install ok half-configured -- Package: dialog Status: install ok unpacked -- Package: debfoster Status: install ok unpacked -- Package: deborphan Status: install ok unpacked
- sudo dpkg –audit reports:
The following packages are only half configured, probably due to problems configuring them the first time. The configuration should be retried using dpkg --configure <package> or the configure menu option in dselect: linux-headers-3.13.0-92-generic Linux kernel headers for version 3.13.0 on 64
- We already know “retry” isn’t the answer here…
- sudo dpkg –configure –pending definitely kicks off the dead-end configuration of the headers…what can cause this to back out, or to remove the stuff that keeps getting triggered?
- As I was about to uninstall Bash for Ubuntu, I (for no reason) ran exit from within the Bash shell, which showed me this new output:
mike@MIKE-WIN10-SSD:/var/lib/dpkg$ exit exit run-parts: waitpid: Interrupted system call Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-headers-3.13.0-92-generic.postinst line 110. dpkg: error processing package linux-headers-3.13.0-92-generic (--configure): subprocess installed post-installation script returned error exit status 4 Setting up dialog (1.2-20130928-1) …
- After a few minutes I just killed the window
- Restarted Bash, didn’t appear to have made any improvements on my situation.
Perhaps it’s time to finally throw in the towel.
Complete rebuild of Bash on Ubuntu
When all else fails, uninstall and reinstall. Thankfully I hadn’t invested a ton of real work into this…
According to this comment, the following command cleans up the whole deal:
Lxrun /uninstall /full
(Coda: In case you get an error re-installing afterwards, try running this command again. I happened to end up with error code 0x80070091 for which I could find no help, but others have reported other error codes too.)
Let’s try this again from scratch.
Hope: I discovered the cbwin project is being actively developed, to enable users of Bash on Ubuntu for Win10 to launch Windows binaries from within the bash environment. I’ll try this for the vagrant/virtualbox combo and report back.
I quickly ran into limits with cbwin in this particular setup, but seemed to have found peace with a hybrid approach.