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/policy-rc.d $ chmod +x /usr/sbin/policy-rc.d then invoke-rc.d becomes a no-op, it will not start or stop anything. Unfortunately the docs are a bit incomprehensible to me .. it seems you can do much complex stuff than that, but I cant help. You may want to look into the package policyrcd-script-zg2 : they know their act. a. Sebastian Dröge ha scritto: > 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 breaks there because of >>> several reasons, including no /sys mounted. >> I tought that this should be handled by invoke-rc.d itself. The manpage >> states that: >> >> invoke-rc.d introduces the concept of a policy layer which is >> used to verify if an init script should be run or not, or if >> something else should be done instead. This layer has various >> uses, the most immediate ones being avoiding that package >> upgrades start daemons out-of-runlevel, and that a package >> starts or stops daemons while inside a chroot jail. >> >> >> So my assumption was that invoke-rc.d detects if it's invoked inside a >> chroot, and doesn't start the service in that case. > > 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. :/ > >
