Ubuntu
upstart package

Bug #430224
Comment #54

Comment 54 for bug 430224

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2011-07-17: Re: [Bug 430224] Re: init: support chroots

#54

Excerpts from Rolf Leggewie's message of Sun Jul 17 14:47:43 UTC 2011:
> My apologies for keeping on mixing up hardy and dapper. I appreciate
> your work, but if you look at comment 27 and my situation it may not be
> enough.
>
> I am running a vserver on some hosting service out there (I actually
> have no idea what OS they use for the host). I am running hardy and
> think time has come to upgrade to lucid. I go through the motions which
> include a reboot and boom, without warning I am COMPLETELY shut off from
> my vserver. ssh does not come up because it relies on a working
> upstart. People lucky enough not to have upgraded yet from hardy are
> currently left without any upgrade path at all and without a warning of
> the potential upstart trouble.
>
> Steve and Daniel warned about potential problems very early on, almost
> two years ago, but it seems that interest in investigating them
> thoroughly was bypassed in favor of pushing upstart out the door.
> That's the beef I have with it.
>
> If thanks to your efforts we see a backport of a working upstart to
> lucid then I think some code changes should be pushed to hardy as well
> (probably into upstart-manager) that will refuse an update hardy->lucid
> when running inside a vserver/chroot when that PPA-solution you provide
> is not available ("Please enable PPA XY before continuing with the
> release update to lucid!")
>

AHH..

I think actually the upstart-dummy program might actually work for
you. I've talked to the author about patching and maintaining it.. but
never knew if there was a good enough reason to do so.

It wouldn't be perfect, but it might work for this situation.

Until then, I believe OpenVZ and LXC work fine for providing lucid
and later. Maybe look into a provider that uses containers like that,
rather than just chroot jails. You get the added benefit of network
isolation. For the provider there is really no additional cost other
than running an extra init for each container. Thats an extra 24k or so.

As far as stopping update-manager from upgrading.. thats not a bad idea
at all. Is that already proposed as a bug somewhere else?

Excerpts from Rolf Leggewie's message of Sun Jul 17 14:47:43 UTC 2011:
> My apologies for keeping on mixing up hardy and dapper.  I appreciate
> your work, but if you look at comment 27 and my situation it may not be
> enough.
> 
> I am running a vserver on some hosting service out there (I actually
> have no idea what OS they use for the host).  I am running hardy and
> think time has come to upgrade to lucid.  I go through the motions which
> include a reboot and boom, without warning I am COMPLETELY shut off from
> my vserver.  ssh does not come up because it relies on a working
> upstart.  People lucky enough not to have upgraded yet from hardy are
> currently left without any upgrade path at all and without a warning of
> the potential upstart trouble.
> 
> Steve and Daniel warned about potential problems very early on, almost
> two years ago, but it seems that interest in investigating them
> thoroughly was bypassed in favor of pushing upstart out the door.
> That's the beef I have with it.
> 
> If thanks to your efforts we see a backport of a working upstart to
> lucid then I think some code changes should be pushed to hardy as well
> (probably into upstart-manager) that will refuse an update hardy->lucid
> when running inside a vserver/chroot when that PPA-solution you provide
> is not available ("Please enable PPA XY before continuing with the
> release update to lucid!")
>