exg9537%ritcv@cs.rit.edu (Ed Garbowski) (04/28/89)
Help! At work we are switching over to an intel 386 running SCO 2.3.1. We have 2 filesystems /u about 90 meg , and the root system 200+ meg. fsck runs fine on the /u system. When using fsck on the root system it starts out fine: /dev/root: ** Phase 1 - Checking Blocks and ... but after about a minute the prompt comes back. No error messages, and never entered Phase 2. I have tried most every fsck option. No help. I have read that at installation time if the root system is large that divvy will prompt for a /dev/scratch file. Well I don't think we were ever prompted for such. Besides, it sounds like this could be over ridden with the fsck /dev/root -t [give it a scratch file if not enough memory - we have 10 meg! ]. I have tried this -t option with a couple of different files on the /u mounted filesys, and also a floppy mounted filesys. No help. The only other reference about this that I have come across is defining SCRATCH in /etc/default/boot. No help. I dont really want to reinstall the whole deal. I could change the size of the /u system and give some space to /dev/scratch if I knew how much to give it, and an indication of wheter or not this is the problem. Any ideas much appreciated. Thanks. -- Reply to this account or to ritcsh!sabin!exg
patg@impch.UUCP (Patrick Guelat) (05/05/89)
In article <1078@cs.rit.edu> exg9537%ucss@cs.rit.edu () writes: +-------------- | At work we are switching over to an intel 386 running SCO 2.3.1. | [....] | When using fsck on the root system it starts out fine: | /dev/root: | | ** Phase 1 - Checking Blocks and ... | | but after about a minute the prompt comes back. No error messages, and | never entered Phase 2. I have tried most every fsck option. No help. +---------------- OOOPS ! We had the same problem a few weeks ago ! I've tried fsck about one hundred times and I never saw more than Phase 1 !! It seems, that it breaks down, must be a really nasty bug. Our solution was to take an old fsck from a Xenix 2.2.1 286 system and that one worked... After that, 'fsck -s' with the new fsck didn't break anymore... Patrick -- \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// // Patrick Guelat, ImproWare Switzerland \ SMART: patg@impch.uucp \\ \\ SUB-NET: ..!altger!impch!{patg,boxdiger} \________ Wasting time is an // // EUNET : ..!cernvax!impch!{patg,boxdiger} \ important time of\\ \\ OTHER : ..!uunet!acad!acadch!impch!{patg,boxdiger} \ living. // //\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
root@mjbtn.MFEE.TN.US (Mark J. Bailey) (05/12/89)
In article <897@impch.UUCP>, patg@impch.UUCP (Patrick Guelat) writes: > In article <1078@cs.rit.edu> exg9537%ucss@cs.rit.edu () writes: > +-------------- > | At work we are switching over to an intel 386 running SCO 2.3.1. > | [....] > | When using fsck on the root system it starts out fine: > | /dev/root: > | > | ** Phase 1 - Checking Blocks and ... > | > | but after about a minute the prompt comes back. No error messages, and > | never entered Phase 2. I have tried most every fsck option. No help. > +---------------- > OOOPS ! We had the same problem a few weeks ago ! I've tried fsck about > one hundred times and I never saw more than Phase 1 !! It seems, that > it breaks down, must be a really nasty bug. Our solution was to take > an old fsck from a Xenix 2.2.1 286 system and that one worked... > After that, 'fsck -s' with the new fsck didn't break anymore... > I just had the same problem too. A long newsfeed the other night (6 hours on a telebit tb+ (yipes!!!) took 14 hours to uncompress on my 80386, sco 2.3 system !!! Something was wrong. At any length, it ran out of space during the operation and I began to notice the whole system really running sluggishly. I then did an 'fsck -s -rr /dev/root' and got the very same halt after Phase 1. A client of mine is running 2.2.4 on an 80386 and I got that fsck as per the above discussion, and got it to run, but I got LINK COUNT TABLE OVERFLOW Continue? and it always answered 'yes' due to the -rr. Well, I ran it once and then tried my 2.3 fsck to see if it would work. No go. I ran the 2.2.4 fsck again and still got the above message, only this time when it was done, it only had to patch up 41 bad inode counts instead of the first time's 62. The above message means that an internal table for fsck that contains allocated i-nodes with a link count of 0 has run out of space (this from the manual), and I assumed that each time, it processed what it could fit in the table and the rest were ignored (as per the above messages). I therefore ran it several times and it got them all taken care of. I then ran the 2.3 fsck and it ran fine now. It appears that where the 2.2.4 fsck can detect the LINK COUNT TABLE being filled up and opt you to continue on anyway to process what you have got, the 2.3 fsck either doesn't support that, or is *supposed* to, but is buggy. Any comments SCO? Mark. -- Mark J. Bailey "Ya'll com bak naw, ya hear!" USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________ VOICE: +1 615 893 0098 | JobSoft UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co. DOMAIN: mjb@mjbtn.MFEE.TN.US | Murfreesboro, TN USA
russ@bbx.UUCP (Russ Kepler) (05/13/89)
In article <478@mjbtn.MFEE.TN.US> root@mjbtn.MFEE.TN.US (Mark J. Bailey) writes: > >It appears that where the 2.2.4 fsck can detect the LINK COUNT TABLE being >filled up and opt you to continue on anyway to process what you have got, the >2.3 fsck either doesn't support that, or is *supposed* to, but is buggy. > SCO hasn't commented so I guess I will: I've got a floppy disk and an associated piece of paper which says: The enclosed Support Level Supplement contains a new /bin/fsck which solves problems experienced with fsck quitting silently under SCO XENIX Operating System Releases 2.3.0, 2.3.1 or 2.3.3 for AT architecture machines. I sounds to me that this is the fix that you need. The label on the disk says: 'Fix# xnx124'; the number is usually all that you would need to order the fix. -- Russ Kepler - Basis International SNAILMAIL: 5901 Jefferson NE, Albuquerque, NM 87109 UUCP: {backboneishsite}!unmvax!bbx!russ PHONE: 505-345-5232