On Thu, Mar 10, 2005 at 12:21:11AM -0500, Eric Jahn wrote:
> 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.
I'm running a Debian system, so my checkroot.sh may be different than
yours. But mine fscks the drive and returns a code to indicate what it
found. It detects a problem if the return code is 4 or larger. However,
from the fsck man page, a > 4 return code can be caused by things that
don't mean the drive's bad, including if the user aborts in the middle
of the fsck. Now, in my version, when fsck fails, it drops you into
single user mode and does not continue to execute init scripts. Once you
log out, it reboots. It executes /sbin/sulogin $CONSOLE to drop you into
single user mode, but I suppose if something was wrong with the
libraries or something, it could choke there. But it seems that even if
that call failed, the next line (reboot -f) would reboot you.
Again, my script's probably different from yours. But you might try
inserting this after it does the fsck:
echo "fsck return code was $?"
exit 0
This will bypass the rest of the script and tell you what the exit code
was. From there you can check man 8 fsck to determine what that exit
code is. Without knowing that, it's hard to say what's really going on.
Paul
-----------------------------------------------------------------------
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:42 EDT