[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Serveur with encrypted partition : 2 steps boot.

Erwan David wrote:
> Bob Proulx a écrit :
> >Am I completely misunderstanding the documentation on this?  Maybe.
> >If so then I am sorry for misleading you along with me.  I am
> >researching the problem.  I think this is completely against the
> >documented interface.
> I added some traces in my policy-rc.d (to a file in /root), and got
> the following resullt :
> boot does not use it (should be startpar), /sbin/service does not
> use it, only invoke-rc.d, which seems to be only used in postinst
> for restarting a service.

You are correct.  I was completely wrong about this.  Sorry.

I couldn't find a plausible connection when I dug through the scripts.
Confused I wrote to the pkg-sysvinit-devel team yesterday and got that
answer as a response this morning!

So apparently policy-rc.d controls the policy to init.d.  I think it
is misnamed.  It should have been policy-init.d instead.  It doesn't
control policy of the rc?.d scripts.

Apparently the *only* purpose is for use in chroots.  Chroots get all
of the package installations and upgrades.  The policy-rc.d controls
access to the init.d scripts instead of having a package postinst
calling '/etc/init.d/foo restart' or 'service foo restart' directly.
Since a chroot doesn't normally get its own init nor have its own
runlevels they aren't ever changed there and so there wasn't a need to
include /etc/init.d/rc in the policy infrastructure.  And so using it
for a real system has no effect at all.

I apologize for leading you astray on this topic and wasting a lot of
your time.  I can only offer that I was also led astray.  Sometimes
documentation can be terribly misleading.

> My solution for the moment is to disable those services (thus losing
> the information about their starting order) through update-rc.d
> disable (which also means each upgrade will now get polluted by
> messages saying their start runlevel are different from default) and
> starting them from my encrypted partition mounting script.

I think you have made the best of the situation.

As far as losing the starting order that doesn't matter at all.  The
'insserv' program dynamically sets that up based upon the LSB headers
of the enabled scripts.  If you were to return those back to being
enabled then insserv would order them according to the current set of
enabled scripts.  So no real information is lost.  It isn't like the
prior release with static legacy hard numbered ordering.

Again let me apologize.  Sorry for the diversion down the rabbit hole.


Attachment: signature.asc
Description: Digital signature

Reply to: