From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (qmail 21637 invoked from network); 10 Jun 1998 15:28:39 -0000 Received: from ts2-27.idf.cyberhighway.net (HELO draken.localnet) (root@209.161.42.57) by mail2.redhat.com with SMTP; 10 Jun 1998 15:28:39 -0000 Received: from localhost (lcr@localhost) by draken.localnet (8.8.5/8.8.5) with SMTP id JAA27863; Wed, 10 Jun 1998 09:24:56 -0600 Date: Wed, 10 Jun 1998 09:24:56 -0600 (MDT) From: "L. C. Robinson" X-Sender: lcr@draken.localnet Reply-To: infynity@cyberhighway.net To: John Covici cc: blinux-list@redhat.com Subject: Re: segmentation fault?? and fsck problems. In-Reply-To: <357e4331.ccs@ccs.covici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: 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. > >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? 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".