VirtualBox Error After Kernel Upgrade

The Error

You're probably here because you're seeing a pop-up error message when trying to start a virtual machine, similar to:

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is probably not loaded.

If you installed or VirtualBox package recently you need to restart the computer for the driver to load.

Alternatively, you may attempt to load the driver by issuing the following command with system administrator (root) privileges:

'/etc/sysconfig/modules/VirtualBox.modules'


The Diagnosis

Although there are a few clues in this message as to what VirtualBox's issue is, there aren't any likely solutions included.  That being said, if you DID install VirtualBox recently and haven't restarted... try that first (and/or try the included command 'sudo /etc/sysconfig/modules/VirtualBox.modules' to attempt to load the kernel module).

The issue here is that VirtualBox requires a loaded kernel module that matches the version of the kernel you're running.  The error likely occurred after a kernel upgrade -- that's been the cause for me EVERY time.  So... the fix?  Install the VirtualBox kernel module that matches your kernel version, of course.


The Solution

In case you want a few details on it...

You can find out the version of the kernel you're running with

uname -r

This is what mine looks like

[user@i7-fedora ~]$ uname -r
3.5.4-1.fc17.x86_64

The result tells you: the kernel version (3.5.4-1), the distribution version (fc17 -- "Fedora Core 17"), and the processor architecture your distro is based around (x86_64).

Fortunately, Fedora's kernel module packages are named using this same nomenclature.  Our needed VirtualBox kernel module, for example, (for this kernel version) is called kmod-VirtualBox-3.5.4-1.fc17.x86_64.  To acquire said module, run this bad boy:

sudo yum install kmod-VirtualBox-3.5.4-1.fc17.x86_64

It's a little long-winded with all the numbers, dashes, and dots...  Fortunately, there is an easier solution.  There is a Fedora metapackage called kmod-VirtualBox.x86_64 whose description is "Metapackage which tracks in VirtualBox kernel module for newest kernel".  Awesome.  You don't have to worry about all of the details.  Just run

sudo yum install kmod-VirtualBox.x86_64

and you should be good to go!  The beautiful thing about the metapackage is that it will show up along with the rest of your system/software upgrades every time there is a kernel upgrade; so, you shouldn't have to worry about it from here on out.

Once the module is installed, you can either reboot or run

sudo /etc/sysconfig/modules/VirtualBox.modules

to get the module loaded.  Then, all that's left is to just enjoy the amazing open source virtualization software as its creators intended.


You've gotten better at Linux! (2)

Dual Booting Linux and OS X Using Grub2

My interest in the frozen-in-time EverQuest Mac server (Al'kabor), and lack of true Apple hardware, has led me to a foray into the Hackintosh world.  Since I am a full-time Linux user at home, I needed the ability to boot into both my existing Linux (Fedora 17) installation and my new OS X 10.8 Mountain Lion installation.  Fortunately, most modern Linux distributions come equipped with a bootloader that is capable of handling this scenario: Grub2.  In very basic terms, a bootloader is software that acts as the start-up link between a system's low level software that handles the initial checks and communication with the installed hardware (eg BIOS) and the higher level operating system(s).

Given the above setup, there are a couple of options for dual booting the system; each could be a viable solution, depending on the configuration.


The Easy Way

If you don't need any additional boot flags to boot OS X successfully, then you can use a built-in grub tool to automatically detect the location and disk type of all operating systems installed on your local drives -- including OS X.  The tool name and syntax varies between distros, but they will all accomplish the same thing.

For Fedora and similar distros (your grub folder may actually be /boot/grub instead):

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

For Debian/Ubuntu/Mint:

sudo update-grub

Both tools use the built-in scripts located in /etc/grub.d to collect info about installed OSes on your machine and create the appropriate entries in Grub's configuration file at /boot/grub2/grub.cfg.  Once it has finished running, you should have two new entries in Grub's boot menu when you reboot; Mac OS X (32-bit) and Mac OS X (64-bit).  Select the appropriate choice for your system and enjoy the seamless transition into OS X.


The Not-Quite-As-Easy Way

If your system requires the use of additional boot flags to boot into OS X, then the easiest solution will be to use Grub to load a Hackintosh-specific bootloader (eg Chimera or Chameleon), then use the Hackintosh boot loader to pass your required boot flags to the OS X system.  This is called chain loading.

Most Hackintosh guides cover installing a boot loader, so I won't go into that here.  I'm going to assume you have Chimera or Chameleon installed already.  To further complicate things, we will need to use boot0, which is a tiny FreeBSD bootloader, to bridge between Grub and Chimera.  Although this file will be on your OS X drive already, the easiest way will be to just grab it from a download of Chameleon boot loader from the website: http://chameleon.osx86.hu/.  Open a terminal in the directory that you just downloaded Chameleon to.

Uncompress the .tar.gz file and locate boot0 within the i386 directory, and copy it to your /boot folder:

tar -xzvf Chameleon-2.*.tar.gz

For Chameleon versions 2.0.*:

sudo cp Chameleon-2.0*/i386/boot0 /boot/

I believe that in Chameleon versions 2.1+, the folder structure has changed in the tarball, so copy the boot0 from here instead:

sudo cp Chameleon-2.1*/usr/standalone/i386/boot0 /boot/

Now that the boot0 file is in the appropriate directory, we need to add an entry for Grub to use it to get to Chimera.  The best way to do this will be to add an entry in /etc/grub.d/40_custom (as opposed to adding it directly to Grub's pre-generated menu file -- ie /boot/grub2/grub.cfg).  The reason is because if we were add it directly to the grub.cfg file, it would be wiped the next time the "grub update" tool is used -- which happens as part of every kernel upgrade.  So, since /etc/grub.d/40_custom is one of the files that are used by Grub's update tool to generate grub.cfg, our OS X/Chimera entry will be kept between kernel upgrades.  So... back to the command line:

First, we need to figure out what our OS X partition's UUID is, according to Grub -- this is different than the UUID that the blkid tool reports.  The easiest way to do that is to run Grub's update tool to generate an entry for OS X.  This won't be the entry that we use, but it WILL give us the appropriate UUID.


For Fedora and similar distros (your grub folder may actually be /boot/grub instead):

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

For Debian/Ubuntu/Mint:

sudo update-grub

Open the generated grub.cfg file in a text editor and scroll down to find the "Mac OS X ..." entry in the file (your grub folder may actually be /boot/grub instead).

sudo nano /boot/grub2/grub.cfg

Copy the entry's UUID to the clipboard.  This will be a 16-digit hexadecimal value (eg 777eaee489759bd8) and will be listed on a line similar to "search --no-floppy --fs-uuid --set=root 777eaee489759bd8".  Now we will open /etc/grub.d/40_custom in a text editor and create our code that Grub will use to generate a menu entry for Chimera.

sudo nano /etc/grub.d/40_custom

Paste the following at the end of the file and change the partition designations on the "set root=" line and the "chainloader" line:


menuentry "Mac OS X (Chimera)" {
insmod part_gpt
insmod hfsplus

#replace this location with
#your OS X partition
set root='(hd1,gpt2)'

#replace this UUID with the UUID from your grub.cfg
search --no-floppy --fs-uuid --set=root 777eaee489759bd8

#replace the (hd0,2) portion with your
#Linux partition designation
chainloader (hd0,2)/boot/boot0
} 


You should be able to get a good idea of which device ids you need to use by running:

sudo fdisk -l

and comparing that info with the output of:

mount

The hard drive listed with GPT will be your OS X drive.  Typically, your drive with OS X on it will be split into at least 2 partitions: a 200MB EFI system partition (fat32), and a much larger partition that holds the OS (hfs+).  You can verify your OS X drive partitions by running:

sudo parted /dev/sdX

(of course, change the X to the actual drive letter of your OS X drive).  Then, at the (parted) prompt enter:

print

This will list the partitions on the drive.  It is worth noting here that, by default, the Chameleon bootloader is installed on your EFI system partition and Chimera is installed on your OS X partition.

A note about partition numbering/lettering in Linux and Grub:
The Linux and Grub partition designations differ a bit.  On my system, my OS X partition is located at /dev/sdb2.  This equates to hd1,gpt2 in Grub (since it's a GPT partitioning scheme).  The root of my Linux system is located at /dev/sda2, which is hd0,2 for Grub (non-GPT).  Linux designates physical SATA drives with /dev/sdX, where X is a letter from a to z.  The first drive is /dev/sda, second drive is /dev/sdb, third drive is /dev/sdc, etc.  After the letter comes a number (starting at 1) that represents the partition within that physical drive.  The first partition on the first drive would be /dev/sda1, second partition on the first drive would be /dev/sda2, etc.  Grub's drive designations are represented as hdY, where Y is a number which starts at ZERO.  Conversely, Grub's partition designations start at ONE.  So, the first partition on the first drive for Grub would be hd0,1, second partition on first drive is hd0,2, first partition on second drive is hd1,1, etc.

Once you have your 40_custom file configuration set, run the "grub update" tool again (refer to the above section again for your distro-specific syntax) to generate a new grub.cfg file which will have our new entry in it.  Once it's done, reboot the PC and select the new entry.  If all goes well, you should be presented with the Chimera bootloader, in which you can use your required boot flags.

Troubleshooting The Chainloader

If you have issues getting from Grub to Chimera, you can select the menu entry in Grub and hit "E" to go into editing mode for it.  Here, you are able to do some basic editing so you can mess with your partition designations (both at the set root='...' line and the chainloader line) or any other syntax errors that might be present.  Once you've made your changes, hit F10 to attempt to boot the revised method.

If you're truly unsure of what your partition designations should look like, back out to the Grub menu and hit "C" to get to a Grub command line.  Use the "ls" command to show all of the partitions that Grub can see.  This could help you get a better understanding of the designation that Grub requires (eg if you need to use a hdX,msdosY convention for an MBR partition).

Note that if you make changes in Grub's edit, they will NOT be saved.  You will need to make those same edits in the /etc/grub.d/40_custom file and re-run the "grub update" tool.


You've gotten better at Linux! (1)