Re: segmentation fault?? and fsck problems.

[covici@ccs.covici.com (John Covici)]

on Wed, 10 Jun 1998 09:24:56 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
<Pine.LNX.3.95.980610055249.26166C-100000@draken.localnet> wrote:
>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.


I did try that, but many things didn't work as expected -- I suspect
the paths are somewhat different, but haven't had time to check.
>> >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?


Well, I think I still had the -a option in there and it still gave an
error, but I didn't have any assistance at the time, so I cannot
verify the error.

I didn't want to redirect the whole sysinit process because I had
already put in those echo statements and didn't want to confuse things
further.  Also, I want the screens to remain the same in case
something else goes wrong where I need sighted assistance.

>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).

But what I really would like to do, if I get that shell I would like
to run screader or whatever I am using and find out what is happening.


>> 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.

Well, some of them do test return codes, but I'd like to see your mods
and maybe get some ideas from them.

>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?

I am not sure which of these programs need an interactive terminal --
maybe it would work and maybe not.

>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.

But maybe its only screader which has something open in read/write
mode and isn't doing any actual writing.


-- 
         John Covici
          covici@ccs.covici.com