[Roger Leigh]
> But, can you detect it if you are already /inside/ the chroot?
> i.e. chroot(2) has been called at some point previously.
Yes. It's a consequence of two well-known properties of the chroot
call: (1) you can call chroot() even if you are already in a chroot, to
chroot yourself fur
Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> Roger Leigh wrote:
>> You can't reliably (or portably) check if you are in a chroot.
> Hmm, if you're root you probably can. Something like this (completely
> untested; probably doesn't even compile):
I agree that this method would work. But, can
On 9/29/07, Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
> Hmm, if you're root you probably can. Something like this (completely
> untested; probably doesn't even compile):
Yes, it works, and AFAIK it has always done. A shorter program to test it:
#include
#include
#include
#include
int
ma
Roger Leigh wrote:
> You can't reliably (or portably) check if you are in a chroot.
Hmm, if you're root you probably can. Something like this (completely
untested; probably doesn't even compile):
DIR *d;
int fd;
struct stat s1, s2;
mkdir("temp", 0700);
d = opendir("/");
f
ke, 2007-09-26 kello 13:49 -0700, Tyler MacDonald kirjoitti:
> Yep... but I still find it a bit annoying that I have to override
> binaries
> like start-stop-daemon or invoke-rc.d when building a chroot. I wish there
> was a way to just set a flag that means "dpkg, don't start/stop any
> services
Mike Hommey <[EMAIL PROTECTED]> wrote:
> > chroot without any admin intervention. If it's not appropriate to run
> > inside a chroot, then the init script should IMHO detect that and not
> > start/restart/stop the service.
>
> The fact is, not all chroot are buildd chroots, and many chroots
> act
On Wed, Sep 26, 2007 at 09:31:36PM +0100, Roger Leigh wrote:
> A Mennucc <[EMAIL PROTECTED]> writes:
>
> > It is all explained in
> > /usr/share/doc/sysv-rc/README.policy-rc.d
> >
> > It seems that all you need to do is to create inside your chroot a
> > simple shell script /usr/sbin/policy-rc.d
A Mennucc <[EMAIL PROTECTED]> writes:
> It is all explained in
> /usr/share/doc/sysv-rc/README.policy-rc.d
>
> It seems that all you need to do is to create inside your chroot a
> simple shell script /usr/sbin/policy-rc.d that just does an 'exit 101'
I would very much prefer that all packages wo
hi
It is all explained in
/usr/share/doc/sysv-rc/README.policy-rc.d
It seems that all you need to do is to create inside your chroot a
simple shell script /usr/sbin/policy-rc.d that just does an 'exit 101'
for example with these two simple commands
$ echo -e '#!/bin/sh\nexit 101' > /usr/sbin/p
* Reinhard Tartler:
> - libxine1 only depends on libraries, that it really needs. This
> leaves users that don't install the recommended packages in the
> situation, that they cannot play their mp3/ogg/etc files.
I guess this will be a non-issue as soon as apt-get installs
recommends by
On Tue, 25 Sep 2007 08:18:39 -0500, John Goerzen <[EMAIL PROTECTED]> said:
> I don't really think that chroot is the appropriate tool for this.
> Why not something more strongly isolated, such as vserver, OpenVZ, or
> even Xen or UML for this?
I've always used an UML for this. I need to
ti, 2007-09-25 kello 08:18 -0500, John Goerzen kirjoitti:
> I don't really think that chroot is the appropriate tool for this.
> Why not
> something more strongly isolated, such as vserver, OpenVZ, or even Xen or
> UML for this?
If the chroot has a policy-rc.d that says not to start daemons, any
John Goerzen <[EMAIL PROTECTED]> writes:
> It is this whole problem that has caused me to never want to try to build
> things in chroots -- the problem of installing things that mess with
> daemons. I've had MTAs restarted, cron restarted, etc.
Sounds like a bug (severity important) to me.
--
On Tue September 25 2007 5:03:32 am Sebastian Dröge wrote:
>
> AFAIK this only happens if specified in some config file that daemons
> shouldn't be started. Whatever, although hal is invoked by invoke-rc.d
> it is started in the buildd chroots. :/
It is this whole problem that has caused me to n
Sebastian Dröge <[EMAIL PROTECTED]> writes:
>> That sounds like "recommends", TBH. The fact that apt used to not
>> install Recommends by default has led to way too stringent
>> relationships; I don't see a problem with packages that are largely
>> unusable without a recommended package as long
On Tue, 2007-09-25 at 13:14 +0300, Lars Wirzenius wrote:
> ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti:
> > Sebastian Dröge schrieb:
> > > does somebody know about a solution to check whether one runs in a
> > > buildd chroot or not? I need this to prevent hal from starting in buildd
tag 439389 help
stop
Sebastian Dröge <[EMAIL PROTECTED]> writes:
>> Would it make sense to demote the dependency on the hal daemon to a
>> Recommends (after all, the hal "client" library should deal with the
>> daemon not running anyway)?
>
> In one of the cases I found this won't be correct:
>
ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti:
> Hi,
>
> Sebastian Dröge schrieb:
>
> > does somebody know about a solution to check whether one runs in a
> > buildd chroot or not? I need this to prevent hal from starting in buildd
> > chroots (via invoke-rc.d from postinst) as it bre
Am Dienstag, den 25.09.2007, 12:23 +0200 schrieb Simon Richter:
> Hi,
>
> Sebastian Dröge wrote:
>
> >> Would it make sense to demote the dependency on the hal daemon to a
> >> Recommends (after all, the hal "client" library should deal with the
> >> daemon not running anyway)?
>
> > gnome-mou
Hi,
Sebastian Dröge wrote:
Would it make sense to demote the dependency on the hal daemon to a
Recommends (after all, the hal "client" library should deal with the
daemon not running anyway)?
gnome-mount depends on hal as it doesn't work at all without hal.
Well, gnome-mount should never
Am Dienstag, den 25.09.2007, 11:35 +0200 schrieb Marco d'Itri:
> On Sep 25, Sebastian Dröge <[EMAIL PROTECTED]> wrote:
>
> > does somebody know about a solution to check whether one runs in a
> > buildd chroot or not? I need this to prevent hal from starting in buildd
> > chroots (via invoke-rc.d
Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer:
> On 25/09/2007 Sebastian Dröge wrote:
> > does somebody know about a solution to check whether one runs in a
> > buildd chroot or not? I need this to prevent hal from starting in buildd
> > chroots (via invoke-rc.d from postinst) as it
Am Dienstag, den 25.09.2007, 11:55 +0200 schrieb Simon Richter:
> Hi,
>
> Sebastian Dröge schrieb:
>
> > does somebody know about a solution to check whether one runs in a
> > buildd chroot or not? I need this to prevent hal from starting in buildd
> > chroots (via invoke-rc.d from postinst) as i
Hi,
Sebastian Dröge schrieb:
does somebody know about a solution to check whether one runs in a
buildd chroot or not? I need this to prevent hal from starting in buildd
chroots (via invoke-rc.d from postinst) as it breaks there because of
several reasons, including no /sys mounted.
My chroots
On 25/09/2007 Sebastian Dröge wrote:
> does somebody know about a solution to check whether one runs in a
> buildd chroot or not? I need this to prevent hal from starting in buildd
> chroots (via invoke-rc.d from postinst) as it breaks there because of
> several reasons, including no /sys mounted.
On Sep 25, Sebastian Dröge <[EMAIL PROTECTED]> wrote:
> does somebody know about a solution to check whether one runs in a
> buildd chroot or not? I need this to prevent hal from starting in buildd
> chroots (via invoke-rc.d from postinst) as it breaks there because of
> several reasons, including
Sebastian Dröge <[EMAIL PROTECTED]> writes:
> does somebody know about a solution to check whether one runs in a
> buildd chroot or not?
You can't reliably (or portably) check if you are in a chroot. You
could (for example) check for the existance of /etc/debian_chroot.
However, this is not guar
Sebastian Dr?ge wrote:
> Hi,
> does somebody know about a solution to check whether one runs in a
> buildd chroot or not? I need this to prevent hal from starting in buildd
> chroots (via invoke-rc.d from postinst) as it breaks there because of
> several reasons, including no /sys mounted.
Maybe
28 matches
Mail list logo
