Re: [SLUG] Evil Spawn of Init

From: Eric Jahn (eric@ejahn.net)
Date: Thu Mar 10 2005 - 00:21:11 EST


On Wed, 2005-03-09 at 12:14 -0500, Eben King wrote:
> You could edit /etc/inittab and replace a failing call to "/sbin/getty
> getty_args" with "/usr/bin/strace /sbin/getty getty_args 2&> some_file".
> Might want to include the date in the filename (or make the call not exit)
> since init will call it over and over. Try calling getty manually from the
> command line (pointed at e.g. tty8).

Eben, this strace worked, and indicated to me that getty couldn't run
because the root filesystem had been set to read-only and many
permissions for commands in /bin and other folders has been revoked..
To figure out where this was happening, I narrowed it down by starting
each rc level script one by one (starting in the rcS directory) until I
saw a hiccup. So essentially, I walked through the same steps init
takes, one command at a time. The S10checkroot.sh script (symlinked
actually to /etc/checkroot.sh) was the culprit and after running it is
where the problems start.

Apparently, looking at the script, it checks fstab and if things don't
look the way it wants, it sets the root filesystem to read only and I
think closes off permissions to important folders as /bin and /lib.
Every script after S10checkroot.sh in rcS failed, and gave messages like
"/bin/rm : permission denied" and "lib/init/readlink : permission
denied", but only if I ran S10checkroot.sh first. So how do I make
S10checkroot.sh behave? I'm not very good with bash scripting, and
every attempt I made to fix it didn't change its permission-blocking
behavior (don't worry, I saved the original). as anyone else dealt with
this crap? My hard disk is fine, it fscks aok and works great until
init runs this stupid script.

-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:27:31 EDT