Re: segmentation fault?? and fsck problems.

["L. C. Robinson" <lcr@draken.localnet>]

On Wed, 10 Jun 1998, John Covici wrote:

> on Tue, 9 Jun 1998 23:08:43 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
> <Pine.LNX.3.95.980609184015.8522B-100000@draken.localnet> wrote:
> >Did you use the "-o remount,ro" option to "mount", to remount root?
> >Thus:
> >mount -n -o remount,ro /
> >(taken from the /etc/rc.d/init.d/halt script).
> 
> Yes, and when I do it it says device or resource busy and will not
> change state.

Humm, the halt script does this only after killing off all other
processes.  Filesystems cannot be umounted when they are in use.
The "fuser" utility can be used to help with this, but changing
to single user state is a more suitable way to do this sort of
thing, for the root filesystem.

> >But this is a hard way to do things, and I never fsck the
> >filesystems this way, except under very unusual circumstances.
> >Fscking automatically during bootup is the natural way to do
> >it, if you have set things properly for this.  Read the
> >tune2fs man page for info on how to make this happen every two
> >weeks or so (time set by you).
 
> It does happen, but I have no idea what is going on.  I did try
> to redirect the fsck output using a command something like fsck
> <options> 2>&1 |tee /dev/ttyS0 (which is where my synthesizer
> is), but it gave a status >2 and dropped me into a shell where
> the system was still in read only mode, and screader wouldn't
> run at all.

Did the fsck run prior to that, with output readable on ttyS0?
I found by experimenting that if you disable the -a flag (I do
this too) and try to redirect the output at the same time, so
as to run interactively, without automatic repairs, fsck refuses
to run, and delivers the following error statement:
"fsck.ext2: need terminal for interactive repairs",
and exits with a error code of 8, which causes rc.sysinit
to drop to a single user shell via sulogin.  If I leave the
-a option in, I can redirect the output to a file (and the
output is much less verbose) via:
exec > fsck-test-output-file
before the fsck statement.  Let me know if you want a copy of my
test script.  Note that the above exec statement remains in
effect till the end of the script, or until another exec
statement is encountered.  Maybe redirection of the whole
rc.sysinit script, as a unit, through the "exec" builtin would be
useful?

The drop to single user shell (sulogin) could be disabled, or you
could just type ^D when that happens, to continue on, as the
prompt directs (I guess you would have to do this without seeing
the prompt?).  But this won't happen if you make sure to use
the -a option to fsck, and if it does happen, it may just
mean you tried to redirect the interactive output, in which
case you have effectively made fsck inoperative (bad).

> I have modified the bootup scripts so that there are extra echo
> statements redirected to the synthesizer so I have some idea of
> what is happening.

But the echo statements only tell you whether the daemons tried
to start, not whether they succeeded.  My modifications to the
"functions" script change all that.

I wonder if the output of the whole boot script complex could
be changed with something like:

exec > /dev/ttyS0 2> /dev/ttyS0 < /dev/ttyS0

at the start of, say, the /etc/rc.d/rc script?
One might have to figure out how to set the protocol of
the serial port first, via stty, for this to work (gettys
normally do this).  I tried this once, when my monitor
went out, but had trouble with it.  How did you get your
echo statements to work?  The same procedure should make
the more comprehensive "exec" work.
 
> By closing down all the loggers, lpd, cron and a couple of
> other processes, I think I can do a safe fsck in read/write
> mode -- at least I tried it a couple of times and got no
> errors.

Sounds pretty risky to me.  If you can't remount it read only, it
means you missed some process still writing to the filesystem.
Killing off everything in root is almost impossible without an
automated init state change.  Probably safer to trust an
automated fsck, even if not seen.  Most users probably don't know
how to interpret any output from fsck anyway, and essentially
ignore it (little documentation is available).  The default Red
Hat boot check script recognizes this, by using the -a option, as
does the e2fsck program, which doesn't clutter your screen with
useless info when you run non-interactively.  You could check
/lost+found after bootup for any recovered files, and do better
than lots of people who CAN see.  Another trick would be to alter
the checks of the exit status of fsck in rc.sysinit, to message
you about success or failure, which is probably about all most
people understand or need anyway.

> I hope this explains my problem in a clearer way than I did
> before.

It's about what I would have guessed.  If I understand you right,
you object to not being able to "see" the fsck.  I would too.
This one is very sticky to get around.  Maybe someone needs to
email the maintainer of fsck with a request for an option or
environmental variable to cause fsck to redirect it's output when
in interactive mode, for accessibility purposes?  Something that
can be added to the line at the boot prompt would be preferable,
since it could be automated through LILO and loadlin.

Maybe redirection of the whole rc.sysinit script, as a unit,
through the "exec" builtin would be useful?

Please let me know how you solve this problem, what works,
since the info could be useful to me.  Come to think of it,
it would be useful to know what doesn't work, too.

-- 
L. C. Robinson
reply to infynity@cyberhighway.net (a family account)

People buy MicroShaft for compatibility, but get incompatibility and
instability instead: then they get to buy upgrades to fix it, and get
still more problems.  This is award winning "innovation".