On 19 June 2014 14:15, Dashamir Hoxha <430...@bugs.launchpad.net> wrote:
> Just for the record, when I install Ubuntu Trusty (14.04) as a chroot
> inside Ubuntu Trusty (14.04) this problem does not happen. The problem
> here is with starting mysql inside the chroot: `service mysql start`. It
> trie
Just for the record, when I install Ubuntu Trusty (14.04) as a chroot
inside Ubuntu Trusty (14.04) this problem does not happen. The problem
here is with starting mysql inside the chroot: `service mysql start`. It
tries to start the mysql of the main (host) system.
The easy workaround for this (wh
# Workaround and future
It may be of interest to observe that future releases of Ubuntu (after 14.04)
will no longer use upstart but systemd.
Ref: [Mark Shuttleworth » Blog Archive » Losing
graciously](http://www.markshuttleworth.com/archives/1316)
In the strict context of this bug report which
I have installed Ubuntu Trusty (14.04) as a chroot inside Debian Wheezy (7) and
this problem happens there too.
The workaround by Martin on the last comment (#58) worked well.
Thanks Martin and Ericks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscr
I've come across this problem while setting up a headless 12.04 server
via debootstrap and chroot. To be able to upgrade or install services
(like mdadm, which requires postfix) I had to use Ericks workaround and
divert initctl.
It worked fine, however, there seems to be something missing in Erick
I've opened bug 826544 against update-manager to propose that
hardy->lucid updates should currently not happen until this ticket is
properly resolved.
It's great to hear that OpenVZ, LXC, Virtuozzo and whatnot hosts are not
affected (if that is indeed the case). I don't know what my hoster is
run
I've opened bug 826544 against update-manager to propose that
hardy->lucid updates should currently not happen until this ticket is
properly resolved. (I guess I should add that the ticket clearly states
that hardy-lucid updates are fine as long as it does not involve an
update in a chroot/vserver
On 07/17/2011 12:52 PM, Clint Byrum wrote:
> 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 vse
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 actuall
When we talk about releases we need to carefully differentiate whether
we talk about host or guest. I'm usually more concerned about the guest
side of things. If you have control over the host your options are
obviosly much better. Although thinking about it, it's not really
pretty, either, I gu
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
Excerpts from Rolf Leggewie's message of Sun Jul 17 09:09:58 UTC 2011:
> Clynt, thank you for taking this up.
>
> My point is essentially the same as was raised by Lukas in comment 27.
> We need to be sure that a lucid guest will work no matter the host OS.
> I'm not opposed to a PPA workaround bu
I see you also attempted to build lucid packages, I guess they were
added after I went to bed last night. None of the packages built
successfully, though.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.
Clynt, thank you for taking this up.
My point is essentially the same as was raised by Lukas in comment 27.
We need to be sure that a lucid guest will work no matter the host OS.
I'm not opposed to a PPA workaround but IMHO some code should be added
probably to dapper somewhere to make sure that i
OK
What can we do about lucid?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/430224
Title:
init: support chroots
To manage notifications about this bug go to:
https://bugs.launchpad.net/ub
Its already available in Natty and Oneiric. It was made as an Ubuntu-
specific patch for 0.9.x.
** Changed in: upstart (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https:/
Thank you, James. Does this ticket need to be reopened for oneiric?
1.3 has not yet been released to any Ubuntu series. I'm surprised
things seem to be working for Clynt. Are you running a self-compiled
package?
Does the host or the guest need to have upstart >= 1.3? I suppose it's
for the hos
Chroot support is now available in Upstart 1.3.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/430224
Title:
init: support chroots
To manage notifications about this bug go to:
https://bugs.
Rolf, this is actually available in natty.
I'm not entirely certain of the mechanics thus far, but I know that
schroot takes advantage of it perfectly. You can see how it works by
setting up an sbuild environment and then schrooting in, and installing
mysql. It will install mysql, and start the up
James, thank you for working on this. Can you please leave a short
comment how this was fixed and when it's due to hit Ubuntu? Are we
going to see a backport of the fix?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https:/
** Changed in: upstart
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/430224
Title:
init: support chroots
To manage notifications about this bug go
Clint, the honest answer is that I don't know :) The problem is that
it's really just a bring-me-back-my-good-old-system-V-init type of hack,
and any boot process that truly relies on upstart doing its more
advanced things (handling dependencies, using triggers, restarting
failed services etc.) wou
The new upstart has a lot of other things that make it a little too
invasive for lucid-backports. Certainly we can create a PPA for it
though.
Peter, would it be that hard to make upstart-dummy work for 99% of cases
with a little bit of TLC development? I feel a bit silly as I just
posted on your
Rolf, my solution is more a hack than a real solution -- it works fine
in the very controlled environment I'm using but even I wouldn't
recommend adding it officially to any distribution. The way I'd go is to
backport the new upstart that is said to include support for chroots
(it'll be need to be
Would it be possible to see something similar to what Peter proposed in
comment 35 available as a package (officially if at all possible)? Not
being able to use the latest LTS as a vserver is a very terrible joke.
I'd even be willing to help with the packaging. Peter, are you taking
the bait?
--
This breakage is really another major nuisance that upstart creates.
Booh! I waited for a while before updating my vserver to lucid assuming
that the wrinkles would be ironed out by now only to find that the
system is now completely unusable (not even ssh will start).
Colin, will that code need t
** Changed in: upstart
Status: Triaged => In Progress
** Changed in: upstart
Assignee: (unassigned) => James Hunt (jamesodhunt)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
https://bugs.launchpad.net/bugs/430224
Title:
Code to support chroot sessions has been written (lp:~canonical-
scott/upstart/session-support), and will hopefully land in the not too
distant future.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
https://bugs.launchpad.net/bugs/4302
We've been hit by this, too and managed to create a workaround that
requires no changes in the initscripts of the services and still allows
starting them the traditional way in a Lucid-based chroot. See the
(quite long) description of or problems and our solution in this blog
post: http://gyp.blogs
I have setup where I put clients in chroots, each client has it's own
chroot. has been running on jaunty, and everything was great.
Now I upgraded one chroot to lucid, and I can't start services in client
chroot:
[chroot] # /etc/init.d/atd start
Rather than invoking init scripts through /etc/init
if you are not able to make the mounts like described above try it like
when using a Live-CD:
# sudo mount -o bind /dev /mnt/dev
# sudo mount -o bind /sys /mnt/sys
# sudo mount -t proc /proc /mnt/proc
# sudo cp /mnt/proc/mounts /mnt/etc/mtab
# sudo chroot /mnt /bin/bash
see also: http://wiki.ubun
The same problem.
I need to run some service in chroot.
I've done:
mount -R /dev /mnt/dev
mount -R /proc /mnt/proc
mount -R /var/run /mnt/var/run
mkdir -m 777 /var/run/mysqld
chroot /mnt
Everything works fine, but still can't figure out how to run simple service!
Why /etc/init.d/mysql start doesn't
This really is a major pain for system builders. Had to work around this
problem today to allow TKLPatch to work with Lucid. My approach was to
temporarily lobotomize upstart, replacing it with a shell script that
reproduces the sysvinit functionality in the old init scripts:
http://github.com/tur
Fixed it for mysql /apache that I installed anyhow.. not for deactivating swap
and what not.
so I could do stop/start mysql , but it still gets connection refused when the
vserver shuts down.
Oh well.
--
init: support chroots
https://bugs.launchpad.net/bugs/430224
You received this bug notific
I followed http://linux-vserver.org/Upstart_issues regarding this
problem in connection with VServer and upstart. It fixed it.
I don't know if this sheds any light over a possible way to do things,
but I hope so :)
Regards
--
init: support chroots
https://bugs.launchpad.net/bugs/430224
You rece
When chrooting on a broken system, I'd like at least to have a way to
start the services manually. I don't care about supervision. Just that,
for example, mysqld is started with the system defaults so that I can
check it's state.
What about adding an option: `start --chroot ` where the
service wou
Using a global upstart instance to manage the chroot wouldn't work -
simply because you want to be able to run a Ubuntu chroot from a Debian
Lenny host, or a RHEL host, or whatever. (We actually serve a Lucid
netboot nfs-root from Debian Etch atm). You can't expect every linux
distribution in the w
Moved this to be an Upstream bug.
I think that the most probably implementation will be that you declare
chroots in /etc/init.conf that you wish the init daemon to manage. init
will then also look in CHROOT/etc/init for jobs, and record these as
belonging to that chroot. All actions on these job
38 matches
Mail list logo
