Re: Editing run level S (was encrypted filesystem that can be mounted remotely?)
On Tue, Jul 11, 2006 at 09:19:08PM +0100, Digby Tarvin wrote:
> Leading on from the earlier posters question about configuring an
> encrypted filesystem that does not interrupt the boot process with
> a password prompt...
>
> Can anyone tell me what the 'Debian way' is to remove something
> (in this case 'cryptdisks') from runlevel 'S'?
>
> The relevent links are:
> /etc/rc0.d/K48cryptdisks
> /etc/rc6.d/K48cryptdisks
> /etc/rcS.d/S28cryptdisks
>
> Ultimately I just need to achieve the equivalent of
> rm /etc/rc[06S].d/*cryptdisks
> but in a way that won't fall faul of the APT system..
>
> I am sure I have seen 'update-rc.d' suggested in the past,
> but the manpage warns:
> Please note that this program was designed for use in package main?
> tainer scripts and, accordingly, has only the very limited functional?
> ity required by such scripts. System administrators are not encouraged
> to use update-rc.d to manage runlevels. They should edit the links
> directly or use runlevel editors such as sysv-rc-conf and bum instead.
>
> indicating that it isn't the approved way to do it..
Maybe this description needs update.
update-rc.d is not well suited as an easy-to-use interactive tool but
certainly works fine. I think use of rm or mv are right as long as you
do it right.
> I tried the graphical runlevel editor 'bum', but it
> gives a message stating:
> Editing in run level S is not allowed!
> Playing with rcS.d symlinks is an administration activity
> requiring deep knowledge of the runlevel system.
> (it also bus-errors when I try to run it on a remote Xterm, but
> that is another story...)
>
> Finally, I tried using 'sysv-rc-conf', and it seems that it did allow
> me to deactivate cryptdisks - although not by just removing the links,
> but instead changed the
> /etc/rcS.d/S28cryptdisks
> symlink to
> /etc/rcS.d/K48cryptdisks
>
> which I suppose has the desired effect, although I am not clear on
> the logic behind doing it this way...
>
> Does anyone know what is 'best practice', and what the logic is
> behind the way things are being done?
>
> Regards,
> DigbyT
> --
> Digby R. S. Tarvin digbyt(at)digbyt.com
> http://www.digbyt.com
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: