Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ICAEN.UIOWA.EDU!dbfunk
From: dbfunk@ICAEN.UIOWA.EDU (David B Funk)
Newsgroups: comp.sys.apollo
Subject: Re: DN3500 refuse to get into DM
Message-ID: <9001160829.AA00173@icaen.uiowa.edu>
Date: 16 Jan 90 08:11:03 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Lines: 42

In posting <1990Jan12.172440.851@me.toronto.edu> Andy Sun <sun@me.utoronto.ca> writes:

> There is a strange thing happen to an Apollo DN3500 ... The problem is
> this:
> 
> The Apollo that has problem is connected to an Apollo ring, consisting
> of two other Apollo DN3000s. It is running SR10.1. The other two machines
> are running SR9.7 (yucky, isn't it?). I don't know if anyone has done
> something to it or it decided to go on strike itself, it just won't
> load DM. I tried soft boot it (shutdown and reboot) and hardware reset
> (press the little white button at the back of it). Everything went
> well (disk check passed, salvage boot volume okay, loading Init okay)
> but that's it. It threw me back to a "Phase II Shell" with a ")" prompt
> instead of loading the display manager and ask for login. I manually
> type in dm to try loading DM from that shell, but all I got was something
> like (pm_$init) 3040001. I can still access its disk from the other SR9.7
> machines (so the network is probably okay), but I cannot get it to do
> anything else. Anyone have seen this kind of thing happened before? Any
> help/suggestions are welcome.

I saw something like this once. I saw 2 machines at another site that were
sick, one wouldn't get out of the Phase II shell, the other wouldn't load
the DM. In both cases it was a user (dumb sys_admin) that caused the problem.
This person had logged in as "root" and had opened a DM edit pad on "/etc/init"
on the first machine and on "/etc/dm_or_spm" on the second. This seriously
wounded these 2 programs so that they couldn't do their job. I would guess
that if the DM itself (/sys/dm/dm) were shot you'd get that kind of problem.
There are possibly other system files that could cause such problems if they
were messed up (such as /sys/env, /etc/sys.conf, or something in /lib).
Try poking around in /sys, /sys/node_data, /etc, & /lib and look for a
system file that has been modified recently that shouldn't have been.
Look in `node_data/system_logs on that machine to see if there's some
kind of error log file that you can read. If you had another sr10 machine
handy it would help alot. You could just start doing 'cmt's on various
system directories. Try starting the "SPM" to see if it is just the DM
that is hurt or something more basic. At the Phase II shell prompt,
type in "spm" to force it to start the server process manager. If the
SPM starts OK then it's something directly connected with the DM.
If the SPM croaks too then its more basic, like a messed up library
or /sys/env.

Dave Funk