Packaging, during OS install and Post OS install

Introduction: In my work environment we use a Ubuntu to essentially do everything with our network, we have our OS boot media highly customized such that it installs software collections specific to each machine it installs on based only off of some LDAP queries performed during the install process. During OS installation not all software packages behave as they do during an installation post OS install. The package I was investigating last Friday is VirtualBox (innotek). It comes with it's own package provided through the Ubuntu repositories and that's the version we're using.

The problem that has come up is that during an OS install VirtualBox fails to install completely. More specifically the package installs all of it's components but the kernel driver it provides does not get built. The other side of this story is that during a post-os install installation of VirtualBox the package installs completely and works as it should each time.

To get to the bottom of this I started by rebuilding a machine and jumping onto a virtual terminal during it's software installation process. I searched through the logs in /var/log/syslog until the words "virtualbox" showed up.

Dec 29 02:36:17 in-target: Messages emitted during module compilation will be
logged to /var/log/vbox-install.log.

I checked that file out and here's what I found.

Makefile:68: *** Error: unable to find the sources of your current Linux kernel.
Specify KERN_DIR= and run Make again.. Stop.

Now it's starting to make sense to me. The virtualbox installer needs the kernel source to compile it's own kernel driver against. But where IS it looking? A little more poking around and I found that it searches for the current kernel directory dynamically. It does a check for if [ -d /lib/modules/`uname -` ] . Sure enough that is the problem. Here's the output of a uname -r run in the installer environment: 2.6.20-15-generic. So what actually exists inside the /lib/modules directory during OS installation?

$ ls -l /lib/modules
2.6.20-16-generic

Not sure how to fix this one 100% yet. The basic logic behind fixing this is going to be (in pseudo code): if [os install] -> then define KERN_DIR=/lib/modules/2.6.20-16-generic. The only thing I can think of doing to check that is to add a few lines in the preseed file we use on our boot media that will create a temp file in the target partition for the installation then when the autoinstall is finished it will remove it. This would allow for any postinst scripts in our packages to check for that files existance and perform the appropriate actions during it's installation.
In the case of VirtualBox we can't edit the package directory due to licensing issues but we have created a meta package that Depends: the VirtualBox package. This allows us to still have some level of control over the installation process. Using this meta package we may be able to do a check for that first time install file and then export the KERN_DIR directory to the shell. However, what I am not sure about is the scope and lifespan of shell variables defined during the preinst of a package in Debian.