From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (qmail 22773 invoked from network); 10 Jun 1998 21:02:28 -0000 Received: from mail.clark.net (HELO loas.clark.net) (168.143.0.10) by mail2.redhat.com with SMTP; 10 Jun 1998 21:02:28 -0000 Received: from ccs.clark.net (ccs.clark.net [168.143.3.15]) by loas.clark.net (8.8.8/8.8.8) with SMTP id RAA05690 for ; Wed, 10 Jun 1998 17:03:46 -0400 (EDT) Received: by ccs.covici.com (UUPC/extended 1.12j); Wed, 10 Jun 1998 16:56:11 -0400 Message-ID: <357ef2eb.ccs@ccs.covici.com> From: covici@ccs.covici.com (John Covici) Newsgroups: blinux-list To: blinux-list@redhat.com Subject: Re: segmentation fault?? and fsck problems. Date: Wed, 10 Jun 1998 16:34:41 -0400 Organization: Covici Computer systems Reply-To: covici@ccs.covici.com Message-ID: References: X-Newsreader: Yarn 0.89 with YES 0.22 List-Id: on Wed, 10 Jun 1998 09:24:56 -0600 (MDT) "L. C. Robinson" in wrote: >On Wed, 10 Jun 1998, John Covici wrote: > >> on Tue, 9 Jun 1998 23:08:43 -0600 (MDT) "L. C. Robinson" in >> 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 >> 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