Updated: September 9, 2015
First of all, the title of this article promises a lot. So let's narrow it down and align expectations. The starting point is you've used VirtualBox before, and had Guest Additions installed in your Linux virtual machines. Now, for some reason, the VirtualBox service no longer runs in your guest operating systems. If you try to install the modules again, you get a weird failure, which points to either a bad kernel configuration, missing sources and headers, and similar problems. The things, none of these make sense.
You have the right kernel sources and headers, but for some reason, VirtualBox is not seeing them, and therefore, the compilation of the main kernel module is failing, which in turn is affecting the way your virtual machines are working. Moreover, this seems to happen almost randomly, and it sometimes comes to bear after kernel updates. With all this in mind and more, we will now attempt to solve the problem using some neat and simple tricks.
Problem at hand
Let's demonstrate with a CentOS virtual machine. You have all the necessary build tools, and we've done this exercise many times before, including when we tried to setup the Nvidia drivers for this operating system. The same drill applies here. But even if you're running other distros, again, the process for obtaining the right tools and software to be able to compile is very similar. Once you get the hang of it, it's easy peasy. However, while building the modules (<mount>/VBoxLinuxAdditions.run), the command fails:
Building the VirtualBox Guest Additions kernel modules
The headers for the current running kernel were not found. If
the following module compilation fails then this could be the
reason. The missing package can be probably installed with
yum install kernel-devel-...
Building the main Guest Additions module [FAILED]
(Look at /var/log/vboxadd-install.log to find out what went wrong)
But if you try to install the supposedly missing package:
Package kernel-devel-... already installed and latest version
Nothing to do
Solution
We must consult the logs, and this is a great troubleshooting exercise, which should help you hone your Linux problem solving skills, the ultimate mission here on Dedoimedo. Open the log file, and glimpse inside. You should start bottom to top, with the last error and try to figure out what happened. One of the more notable errors will be:
Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR=<directory> and run Make again. Stop.
Interesting. Seems like VirtualBox really does not see our kernel sources. Let's fix then, and then run the command again to see whether we've fixed the problem we're facing.
export KERN_DIR=/usr/src/kernels/`uname -r`
Still, no good. We need to look for a different error. Indeed, going back to the installation problem, the script complained about headers rather than sources. Which means that our issue most likely lies elsewhere. And browsing through the logs once more, with some extra insight. One of the lines - ignore the specific kernel version, it's not important.
grep: /lib/modules/3.10.0-123.20.1.el7.x86_64/build/include/
linux/version.h: No such file or directory
This seems like a weird bug almost, because we know that we have the headers in place, as the yum command returns. If we manually cd into the /lib/modules directory for the running kernel, we can see that we're actually facing a broken symbolic link.
The build link points to a relative path, which is never a good idea, and thus, VirtualBox is unable to find the expected software. We will fix this by using an absolute path, and thus avoid the issue altogether.
cd /lib/modules/`uname -r`/
ln -sf /usr/src/kernels/3.10.63-11.el7.x86_64 build
Now, the symbolic links has been fixed:
And we can merrily compile:
Conclusion
We've reached the end of our tutorial, that little wiser, smarter, more relaxed, happier. These kind of problems can really drive people insane, because there are dozens of false positive symptoms that could cause similar errors. But if we exclude the build issues, recall that this used to work fine, then we can forget about VirtualBox vs. kernel incompatibility, and look somewhere else.
In our case, a badly implemented symbolic link is the source [sic] of all our problems. The reason for that, I'm not sure, or why it changed, but some of the installed packages may have changed it, or something in the system decided to misbehave. The important bit is that we understand the work flow, and we can trace it back, and fix the issue. Awesome right? Well, that makes our guide complete. Enjoy.
Cheers.