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 stdio.h
#include sys/types.h
#include
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 you
[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
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(/);
fd =
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'
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 worked
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 that just
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
actually do
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!...
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 no
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.
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
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 it breaks
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: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 from
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, 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-mount depends on hal
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 breaks there
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:
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
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 as they
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
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.
--
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
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
* 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
26 matches
Mail list logo
