Am Mittwoch, den 02.12.2009, 13:46 +0100 schrieb John Feuerstein: > >> Do you have a /sbin/init process with pid 1 within your guest? > > > > Yes, I have, but it seems it has been virtual process. > > > >> Did you restart the guest after the upgrade, and more important, > >> is the running init process provided by the old sysv-init or by upstart? > > > > I tried restarting the VPS with plain as style, but I was unable to do so. > > Then I removed the style file from the guest's configuration and I > > succeeded to restart the guest without an error (means that the guest has > > been started by using 'sysv (default)' style). Next I entered inside the > > guest and noticed that the 'cron' daemon is not started. I tried to > > restart this daemon, but I did not succeed. > > The default sysv init style is not compatible with upstart. Most > services (like cron) are migrated from /etc/init.d/ and /etc/rcN.d/ init > scripts to upstart jobs in /etc/init/. > > So you really need the combination of plain, a patched upstart and the > faking of upstart events (to trigger upstart to start some jobs). Can > you give some more detail why you're unable to start the guest with plain? Also make sure you have disabled / moved away all upstart services from /etc/init/ that could possibly fail, hang or simply not work in a vserver. For me it looks like a single service failing to start will prevent upstart from starting further services. Especially dbus seems to be difficult. It usually won't start if /var/run/dbus/ inside the vserver already exists. stop dbus; start dbus inside the vserver won't work also unless you remove that dir. Maybe making /var/run a tmpfs will be the best way to deal with this regarding the initial vserver start (on native ubuntu its a tmpfs too). Tom