ananda@gpu.utcs.toronto.edu (Skye Stollmeyer) (08/23/88)
In article <269@hawkmoon.MN.ORG> det@hawkmoon.MN.ORG (Derek E. Terveer) writes: >In article <6808@well.UUCP>, dave@well.UUCP (Dave Hughes) writes: >> [First problem] >> Secondly - if modem-callers who do NOT have terminal emulation >> programs run it - plain tty mode - the whole session is >> punctuated by OOPS's (coming from curses, I guess), and is >> totally unsatisfactory. > >I've run into the exact same problem that you have seen when entering new >terminals into the /etc/termcap file. > >Apparently, the OOPS is an exclaimation of suprise by curses when it encounters >things in the termcap file it doesn't understand. This doesn't seem to be a >documented feature. I have *not* seen this problem in terminfo files. > >I have seen the OOPS result in two different cases: > > 1. Any kind of capatilized capabilities in the termcap entry, such as > "AL", etc. Just delete all capatilized capabilities. These are > mostly "multiple commands" anyway, such as >1 line delete, etc., > which vi doesn't seem to use anyway! (arg! (:-() > > 2. Any time there are the following type of push strings in the > capability, for example, %p1 or %p2. I simply deleted these strings > with "1,$s/%p[12]//g" in vi. The removal of these substrings from > the capabilities removed the obnoxious OOPS from the screen and > didn't seem to affect the curses capability. > >Good luck, hope this helps! > >derek I've run fsck a number of times in straight succession and it continues to find the same bad inode count in superblock, another bunch of blocks to salvage from who knows where, even though i always answer yes to all the questions. The number of blocks in the system is always slightly different though. Is fsck known to be broken in this way? I've heard it is known to happen after recompiling vpix or other device drivers into the kernel.
usenet@nancy.UUCP (Usenet file owner) (08/24/88)
I am having the same trouble. I think it started happening after installing CGI and drivers. I can't get df to report the correct number of free blocks in the root file system. I somehhow fixed it once and then it broke again. The system has had a number of strange problems which seem to be and some definitely are related to the root file system running out of free blocks and at the same time reporting that it has some. I would be interested in hearing any suggestions for solving this problem. ==larry --------------------------- LARRY SHIELDS UUCP: ...msudoc!lunapark!larry P.O. Box 6159 BIX: lshields E. Lansing, MI 48826 Compuserve: 70277, 3677 BBS: lunapark 1200/2400 8-1-N 24hrs 7 days a week (517) 487-3356 login: bbs
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/27/88)
In article <663@nancy.UUCP> las@frith.UUCP (Larry A. Shields {runs Lunapark}) writes: | | I am having the same trouble. I think it started happening after | installing CGI and drivers. I can't get df to report the correct | number of free blocks in the root file system. I somehhow fixed | it once and then it broke again. The system has had a number of I've seen this trying to diddle a mounted file system, but it seems to work if you do it in maint mode. You can also use the "-rr" (recover root) flag to write out the corrected superblock and then reboot. Sometimes a sync will help, but not all the time. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me