hugh@hoptoad.uucp (Hugh Daniel) (08/17/88)
> liam@cs.qmc.ac.uk (William Roberts) wrote: Haveing fixed some of the bugs that liam@cs.qmc.ac.uk pointed out in his bugreport months ago, I guess it would be better to post them to this group insted of just hopeing things are better next time round. > 3. FSCK Problem This is a problem with the boot scripts, the program /bin/pname is not getting run before non root files systems are fsck'ed. To fix, put a line like "/bin/paname -a" in /etc/bcheckrc near the begining. Then commment out the old "pname -a" in brc (You don't have to do this, all it will do is give some strange useless error messages). > 4. /etc/NETADDRS has no apparent effect This file seems to be used by the software that deals with the ehter card. If you get this IP adderss out of sync with the *REAL* one in /etc/hosts then you will have a broken network after the next boot. > 1. "sync" and "powerdown" do not fully sync the disk? This is a standard system five problem ("Considder it Sub..."). What I now do for ALL non crash reboots is to become root, do a "sync;sync;umount -a" then a "sync;powerdown" or reboot. This will do a good job of saveing the non root filesystems from damage, but the root is still fryed on reboot much of the time. (Question: Has anyone else run into cases where fsck finds a problem, reboots, then finds ANOTHER problem so bad it has to reboot a second time? I have seen this in A/UX and never elsewhere.) > 1. dumpfs missing from our 80 Meg disk Also restore, rdump, rrestore and rmt, all of which would be usefull at our site. As things stand now since I have to work hard to backup my A/UX box I never put hard work that I would not want to lose on my A/UX system. Everything lives on a Sun, this also gets around the problem of 14 or less character file names. ||ugh Daniel hugh@toad.com Grasshopper Group, 415/668-5998 hugh@well.uucp 212 Clayton St. San Francisco CA94117
jtkohl@athena.mit.edu (John T Kohl) (08/17/88)
In article <5123@hoptoad.uucp> hugh@hoptoad.uucp (Hugh Daniel) writes: > ... > (Question: Has anyone else run into cases where fsck finds a > problem, reboots, then finds ANOTHER problem so bad it has to > reboot a second time? I have seen this in A/UX and never > elsewhere.) > ... Yes. We see this very often here at Project Athena, with the BSD filesystem. If /etc/passwd gets corrupted in some fashion (say, a bad link count), fsck will happily re-set it and cause a reboot. But since fsck uses /etc/passwd to display owner names of broken files, the kernel will update the inode when fsck closes the file. So fsck has absolutely no chance of ever fixing this problem; each reboot turns up the same problem. Manual intervention is needed. John Kohl <jtkohl@ATHENA.MIT.EDU> Digital Equipment Corporation/MIT Project Athena (As usual, the opinions expressed above do not necessarily reflect the opinions of my employer. :-)
pokey@well.UUCP (Jef Poskanzer) (08/18/88)
In the referenced message, hugh@hoptoad.uucp (|-|ugh Daniel) wrote: } (Question: Has anyone else run into cases where fsck finds a } problem, reboots, then finds ANOTHER problem so bad it has to } reboot a second time? I have seen this in A/UX and never } elsewhere.) When I was using pre-release A/UX, I would typically reboot once or twice a day. fsck would find and fix a problem about on about half of these reboots. Maybe once in two weeks, it would do a double reboot as you describe above. And twice in N months, it went into continuous reboots. fsck would claim to have fixed the problem, reboot, and then do exactly the same thing again. When I showed this to a wizard he mumbled something about fsck not flushing all its buffers -- sounds pretty dangerous to me! Anyway, I haven't used A/UX since it was released, and I assumed all these problems were fixed. Apparently not. --- Jef Jef Poskanzer jef@rtsg.ee.lbl.gov ...well!pokey It's hard to see the forest when you're one of the trees.
karish@denali.stanford.edu (Chuck Karish) (08/18/88)
In article <5123@hoptoad.uucp> hugh@hoptoad.uucp (Hugh Daniel) writes: > (Question: Has anyone else run into cases where fsck finds a > problem, reboots, then finds ANOTHER problem so bad it has to > reboot a second time? I have seen this in A/UX and never > elsewhere.) I've seen this happen on an old version of AIX (IBM's port of System 5 rel. 2). The third fsck found no errors. Chuck Karish ARPA: karish@denali.stanford.edu BITNET: karish%denali@forsythe.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041
jr@oglvee.UUCP (Jim Rosenberg) (08/23/88)
From article <6836@well.UUCP>, by pokey@well.UUCP (Jef Poskanzer): > When I was using pre-release A/UX, I would typically reboot once or twice > a day. fsck would find and fix a problem about on about half of these > reboots. Maybe once in two weeks, it would do a double reboot as you > describe above. And twice in N months, it went into continuous reboots. > fsck would claim to have fixed the problem, reboot, and then do exactly > the same thing again. When I showed this to a wizard he mumbled something > about fsck not flushing all its buffers -- sounds pretty dangerous to me! I probably shouldn't stick my nose into this, since I don't have a Mac II and don't run A/UX. But it seems to me that the better part of wisdom in dealing with fsck is to know how to boot a "lifeboat" UNIX system from a floppy, and fsck your "raw" hard disk root file system while it's *UNMOUNTED*. This would allow any number of passes through fsck without any auto reboots. Unfortunately, there are more versions of UNIX on personal computers than you can shake a stick at that *DON'T TELL YOU* how to create a bootable floppy. If your A/UX documentation doesn't tell you how to run fsck with your hard disk off-line when working with a bootable floppy, scream like hell. There are cases where booting the floppy is the only safe thing to do, unless you simply decide to bite the big one and restore the whole damn disk from floppies. -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
dwb@Apple.COM (David W. Berry) (08/25/88)
In article <271@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes: >From article <6836@well.UUCP>, by pokey@well.UUCP (Jef Poskanzer): >> When I was using pre-release A/UX, I would typically reboot once or twice >> a day. fsck would find and fix a problem about on about half of these >> reboots. Maybe once in two weeks, it would do a double reboot as you >> describe above. And twice in N months, it went into continuous reboots. >> fsck would claim to have fixed the problem, reboot, and then do exactly >> the same thing again. When I showed this to a wizard he mumbled something >> about fsck not flushing all its buffers -- sounds pretty dangerous to me! > >I probably shouldn't stick my nose into this, since I don't have a Mac II and >don't run A/UX. But it seems to me that the better part of wisdom in dealing >with fsck is to know how to boot a "lifeboat" UNIX system from a floppy, and >fsck your "raw" hard disk root file system while it's *UNMOUNTED*. This would >allow any number of passes through fsck without any auto reboots. Well, on A/UX it's pretty simple. You boot the Mac OS, run sash and instead of launching unix, you run the standalone fsck. The standalone environment allows you to run many of the common utilities (dd, cp, mv, rm, ed, fsck, fsdb, and more) It's not a bootable floppy based unix, but it does solve most of the problems. >-- >Jim Rosenberg pitt >Oglevee Computer Systems >--!amanue!oglvee!jr >151 Oglevee Lane cgh >Connellsville, PA 15425 #include <disclaimer.h> Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry apple!dwb@sun.com dwb@apple.com 973-5168@408.MaBell