Ideally, you should never end up with a hosed system to the point that Upstart cannot start. If you do find yourself in this situation, please help fix Upstart so that others will not be affected in future.
If you get completely stuck, traditionally the next has been to try init=/sbin/sulogin on the kernel command line, then to try to manually remount the filesystems as read-write and to bring up the services using /etc/init.d/xyz start. Under a native Upstart system, this method is not available and instead the start command is used to spawn the remaining jobs, but that will not work until Upstart itself has been started first.
Note that the main upstart absolutely, positively, must be running as pid=1 (the first process). If the daemon is started under another pid, it is treated as an equivalent to telinit for compatibility reasons. Therefore when Upstart is run it must replace the first process.
Specify init=/sbin/sulogin on the Linux kernel commandline, e.g. in the grub bootloader
Create /etc/init/sulogin.conf using cat >> /etc/init/sulogin.conf, with the following contents:
start on startup exec openvt -c 7 -w sulogin
start on startup console owner exec /bin/bash
exec /sbin/initthus replacing the current shell with Upstart, and then auto-spawning a new shell
From this point onwards, start xyz will allow bring up D-Bus and other core services.
By default Upstart will start all of the jobs it can do when started. If one of these disrupting the boot process then it will be necessary to instruct the Upstart process itself to start, but not to act upon any events by default. This cannot currently be done, but is on the TODO list (as of 2009-09-25).
If the 'just upstart' bug is fixed, the workaround to keep a shell will not work!
A small forkinit utility can fix it though, pseudo code for it:
if pid == 1 do fork if pid == 1 do exec init exec shell
Start Upstart using:
exec /sbin/init --debug