[Bug 430224] Re: init: support chroots

Clint Byrum clint at fewbar.com
Sun Jul 17 16:52:46 UTC 2011


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?

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/430224

Title:
  init: support chroots

Status in Release Notes for Ubuntu:
  Fix Released
Status in Upstart:
  Fix Released
Status in “upstart” package in Ubuntu:
  Fix Released
Status in “upstart” source package in Karmic:
  Won't Fix

Bug description:
  Binary package hint: upstart

  $ sudo chroot /media/karmic dpkg --configure -a
  Setting up cups (1.4.1-1) ...
  update-rc.d: warning: /etc/init.d/cups missing LSB information
  update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
  Rather than invoking init scripts through /etc/init.d, use the service(8)
  utility, e.g. service cups start

  Since the script you are attempting to invoke has been converted to an
  Upstart job, you may also use the start(8) utility, e.g. start cups
  start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
  invoke-rc.d: initscript cups, action "start" failed.
  dpkg: error processing cups (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   cups

  
  WORKAROUND: Create an executable /media/karmic/usr/sbin/policy-rc.d with this in it:
  #!/bin/sh
  exit 101

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/430224/+subscriptions




More information about the foundations-bugs mailing list