>>> 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? Here is the error I got when I tried to restart upgraded guest immediately after the upgrade finished: # vserver karmic restart # init: missing runlevel Try `init --help' for more information. I also tried to start the guest after I deleted pretty much everything from inside the guest's '/etc/init' directory, but again I have gotten the same error. I deleted the style file from the guest's configuration and the guest started without complaining of any error and I did not see any service failure during the start up procedure. But then I noticed that the cron service is not started inside the guest and when I tried to restart this service I got the following error: restart: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused TIA, Dragan Saragin -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.