[2282] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: Ultra-60

daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Mon May 22 20:04:43 2000

Message-Id: <200005230004.UAA00994@riff-raff-w20.mit.edu>
To: Michal N Lusztig <miki@MIT.EDU>
Cc: ops@MIT.EDU, release-team@MIT.EDU
In-Reply-To: Your message of "Mon, 22 May 2000 14:30:04 EDT."
             <200005221830.OAA10525@gypsy.mit.edu> 
Date: Mon, 22 May 2000 20:04:41 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>

	I believe I've figured out what the problem with these machines
is.  Looking around on SunSolve I found Sun Bugid 20987, which describes
a problem with similar symptoms to what I'm seeing which occured after
installing patch 106541-05 or 106541-07.  We have 106541-09 installed on
our Solaris 7 machines, so I didn't think this was likely, but I
followed up on it.  Part of the instructions in the bug id resolution
called for:

grep sysmsg /etc/name_to_major

This is relevant to the devices /devices/pseudo/sys* on a Solaris 7
machine (these devices don't exist on a Solaris 2.6 machine).  The copy
of /etc/name_to_major in the Solaris 7 /os pack has:

sysmsg 97

However, we're installing our own /etc/name_to_major out of the /srvd
that appears to be based on the Solaris 2.6 one that doesn't have this
entry, and is otherwise significantly different from the Solaris 7 one.
Replacing /etc/name_to_major on my Ultra 60 with the version out of /os
made it boot without any problems.

miki:  Can we update the version of /etc/name_to_major in the source
tree with one derived from the Solaris 7 file?  Do we know for a fact
that we need to continue to install our own version of this file?

Garry


home help back first fref pref prev next nref lref last post