Comment 35 for bug 430224

We've been hit by this, too and managed to create a workaround that requires no changes in the initscripts of the services and still allows starting them the traditional way in a Lucid-based chroot. See the (quite long) description of or problems and our solution in this blog post: http://gyp.blogs.balabit.com/2011/01/using-upstart-in-a-chroot/

To quote the most important part:

Thus we wrote “upstart-dummy“, an almost-drop-in replacement for Upstart. It’s a Python script that can be put in place of the standard Upstart installation in /sbin/initctl. The commands “start”, “stop”, “restart”, “reload” and “status” are symlinked to /sbin/initctl by default and this script is able handle it when it is called through these symlinks. It tries to find the appropriate config file for the service, parse it and run the necessary commands, including pre-start, post-stop etc. scripts that can be found in them. What it cannot do though, and this is why it’s not a complete replacement, is to work as proper standalone init process: it is not able to figure out the dependencies and does not know what services it needs to start on a certain runlevel. But if you’re using it on a system that kept the System V init compatibility layer (and Lucid is one of them), all you need to do is to re-add the symlinks in “/etc/rc*.d” to “/etc/init.d/“, which will be a symlink to “/lib/init/upstart-job“, which will call this fake Upstart daemon, which will, this time, indeed work in a chroot. After this, you can simply start “/etc/init.d/rcS” and “/etc/init.d/rc 2” (which are still there in a stock Lucid) which will boot the chrooted system properly.

It might not be suitable for everyone but it did the job for us.