My original query:
=>
=> Since this has happened on 3 of our 4/60M1's, I assume it is not uncommon,
=> but I have not seen a description/resolution of the problem before.
=>
=> Hardware: 4/60M1 with 2, 104MB disks
=> OS: SunOS 4.0.3 (some patches)
=>
=> Problem:
=> (1). When a 4/60 cpu is powered-down (e.g., to move to a new location), on
=> power-up/reboot the boot-check of one of the partitions (not always the
=> came one) gives a
=> CANNOT READ BLOCK <n>
=> UNEXPECTED INCONSISTANCY: RUN fsck MANUALLY ...
=> and the disk is not mounted R/W. The 4/60 was 'shutdown -h' and was at the
=> '>' prompt before powering-down.
=> (2). This is NOT the 'head-stick' problem; the disk -- and other partitions
=> on it -- are apparently recognized ok.
=> (3). Not every attempt at reboot gives the same <n>.
=> (4). running fsck manually does no good; it fails.
=> (5). SO FAR, powering down the CPU again and then repowering it has fixed
=> the problem, but I am worried that the next time, it won't.
=>
=> Questions:
=> (1). Does anyone know what causes this; are we not shutting the system(s)
=> down properly?
=> (2) . Is it an indication of a deeper problem which can be (should be)
=> fixed before it gets worse?
=>
=> Thanks in advance for your help.
=>
=> Gordon Lentz ody1.uchicago.edu
=> Enrico Fermi Institute
=> Laboratory for Astrophysics and
=> Space Research
=> University of Chicago
=>
I got 4 responses, for which I thank the respondees, as follows:
=> From: mike@inti.lbl.gov (Michael Helm)
=>
=> It's not clear from your posting how you shut down the
=> systems before powering off. You should run /etc/shutdown
=> or /etc/fasthalt or the like first; perhaps you already
=> are doing this.
=>
It was not emphasized in my text: yes, I do use 'shutdown' routinely.
=> From: Ravi Kolagotla <eufl@src.umd.edu>
=>
=> I used to have this problem with my Sun 3/180 server.
=> The partition that gave this problem was being used
=> as root space for diskless clients. Shutting down the
=> server while these clients were still accessing files
=> caused this.
=>
=> Are you using this problem partition as /export/root
=> or /export swap?
=>
This was not my problem: the problem partitions were not used as
/export/root or /export/swap.
=> From: selig@centaur.msfc.nasa.gov (Bill Selig - SysAdmin)
=>
=> The only thing you should have to do to shutdown prior to power off is
=> use teh 'shutdown(8)' command and then do a 'halt(8)' command (a few
=> syncs before the halt never hurt. That preserves the integrity of the
=> filesystems.
=>
=> If you are already doing those things, then I don't know what to tell you.
=>
=> Regards,
=> ===============================================================
=> US MAIL: Bill Selig NASA/MSFC ES53
Huntsville, Al 35812 USA
=> TPC: (205)-544-7608
=> FTS: 824-7608
=> INTERNET: selig@centaur.msfc.nasa.gov [128.158.10.96]
selig%sam.span@fedex.msfc.nasa.gov
=> SPAN: sam::selig
=> BITNET: selig%sam.span@star.stanford.edu
=> UUCP: uunet!selig@sam.SPAN -OR- uunet!sam.span!selig
=> ================================================================
I was using 'shutdown -h ...', which I think is equivalent, but not doing
additional, explicit 'sync's.
The following may very well be the culprit -- and certainly should be of
interest to anyone running 4.0.3c!
=> From: Wilson N G <noel@essex.ac.uk>
=>
=> It is a well-known bug in 4.0.3c. I would STRONGLY recommend upgrading the
=> O.S. as the bug is not limited to the effects you are seeing - fsck can
=> destroy the disk (i/o gives strange errors, transfer sizes can be wrong,
=> etc). The bug normally only applies to certain types of disk (mostly
=> Micropolis).
=>
My thanks again to the group for helping me out. Watch the list for my next
plea for help in about an hour!
Gordon Lentz ody1.uchicago.edu
Enrico Fermi Institute
Laboratory for Astrophysics and
Space Research
University of Chicago
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:17 CDT