[comp.sys.sgi] dvhtool error during upgrade

xxwrp@picasso.lerc.nasa.gov (Bill Palenske) (01/04/91)

	While upgrading a PI from 3.2 to 3.3.1, I got the following:

	Interrupt/Error:

	No room in volume header for sash.

	( I assume this really means what is says, and not: No room in 
	/tmp. )

	/etc/dvhtool -v creat /root/stand/sash sash $rbase $vhdev

	Later on I got the same sort of message for symmon.  

	(For what it's worth, binaries were copied to /stand.)

	This seems to imply, at least the possibility, that in standalone
	use sash and symmon would not be located in the volume header.  

	However, since I have not encountered any problems yet.  I guess 
	this means the old 3.2 sash and symmon are still in the vh
	and still work? 

	My questions are:  Why did this happen? and how do I fix it?

	BTW, what does symmon do?

	email will do, I will summarize.  Thanks.

	xxwrp@convx1.lerc.nasa.gov

olson@anchor.esd.sgi.com (Dave Olson) (01/05/91)

In <1991Jan3.220758.17838@eagle.lerc.nasa.gov> xxwrp@picasso.lerc.nasa.gov (Bill Palenske) writes:

First, this is documented pretty clearly in the release notes.  I know
the release notes are long, with lots of stuff most people don't care
about, but I really would recommend reading them before installing...

| 	While upgrading a PI from 3.2 to 3.3.1, I got the following:
| 	Interrupt/Error:
| 	No room in volume header for sash.
| 
| 	( I assume this really means what is says, and not: No room in 
| 	/tmp. )
Yes.
| 
| 	/etc/dvhtool -v creat /root/stand/sash sash $rbase $vhdev
| 
| 	Later on I got the same sort of message for symmon.  
| 
| 	This seems to imply, at least the possibility, that in standalone
| 	use sash and symmon would not be located in the volume header.  
| 	However, since I have not encountered any problems yet.  I guess 
| 	this means the old 3.2 sash and symmon are still in the vh
| 	and still work? 

The binaries that were there are still there, so you have an older
version of sash and symmon, which is rarely a problem.  One of the
'solutions' mentioned in the release notes is to just leave things
alone.  There were no significant bug fixes in either program.

| 	My questions are:  Why did this happen? and how do I fix it?

It happened because (almost certainly) your disk was originally setup
by the factory or you under IRIX 3.1.  At that time, symmon wasn't
being shipped, and the default volume header size wasn't made large
enough to allow for it in all cases.  It may be that you already had
symmon installed, but that sash, ide, and symmon grew just enough larger
to cross the boundary of the available space.  I would remove symmon
if present, and not re-install it, since it appears that you don't need
it (see below).

| 	BTW, what does symmon do?

symmon is the kernel symbolic debugger.  It appears that at sometime
you chose to install the subsystem containing the kernel debugger,
either through step mode, or by choosing 'all'.  It appears that you
aren't using the kernel debugger, so I would simply remove the subsystem,
thus giving you more disk space.  You'll need to remove symmon from
the volume header yourself with dvhtool.

NOTE: All PI's shipped with 3.2 were inadvertantly shipped with symmon
in the volume header (but not in /stand) through an error in the
system burnin process.  So if you have symmon in the volume header,
but not on the disk, you might as well remove it to prevent confusion
and possible out of space messages with the command:
	dvhtool -v d symmon -v l

--

	Dave Olson

Life would be so much easier if we could just look at the source code.

xxwrp@picasso.lerc.nasa.gov (Bill Palenske) (01/10/91)

	I posted the following recently, and what follows is what
	I got back.

>
>	While upgrading a PI from 3.2 to 3.3.1, I got the following:
>	Interrupt/Error:
>	No room in volume header for sash.
>	( I assume this really means what is says, and not: No room in 
>	/tmp. )

	It does mean: No room in volume header.

>	/etc/dvhtool -v creat /root/stand/sash sash $rbase $vhdev

>	Later on I got the same sort of message for symmon.  

	( symmon is a debugger used by kernel developers. )

	NOTE: All PI's shipped with 3.2 were inadvertantly shipped with symmon
	in the volume header (but not in /stand) through an error in the
	system burnin process.  So if you have symmon in the volume header,
	but not on the disk, you might as well remove it to prevent confusion
	and possible out of space messages with the command:
		dvhtool -v d symmon -v l

>	This seems to imply, at least the possibility, that in standalone
>	use sash and symmon would not be located in the volume header.  
>	However, since I have not encountered any problems yet.  I guess 
>	this means the old 3.2 sash and symmon are still in the vh
>	and still work? 

	This is the case.

>	My questions are:  (1) Why did this happen? and (2) how do I fix it?

	(1) It happened because (almost certainly) your disk was originally
	    setup by the factory or you under IRIX 3.1.  At that time, symmon
	    wasn't being shipped, and the default volume header size wasn't
	    made large enough to allow for it in all cases.  It may be that
	    you already had symmon installed, but that sash, ide, and symmon
	    grew just enough larger to cross the boundary of the available
	    space. 
		( Someone has gotten bigger in 3.3, as I suspected; but I
		like to hear it affirmed )
	    I would remove symmon if present, and not re-install it,
	    since it appears that you don't need it.


	(2) a. The binaries that were there are still there, so you have
	       an older version of sash and symmon, which is rarely a problem.		       One of the 'solutions' mentioned in the release notes is to just
	       leave things alone.  There were no significant bug fixes in
	       either program.

	    b. As root ( of course ):
	       #dvhtool -v list
	       (shows you what's there)
	       #dvhtool -v delete sash
	       #dvhtool -v delete symmon
	       #dvhtool -v add /stand/sash sash
	       (you also don't need to reformat....)

	-------

	I haven't done this yet; I'll let you know if I have any problems.
	( Sooner or later, it seems to me you'll want to do (b).)

	In addition, someone said:

		First, this [ problem ] is documented pretty clearly in the
		release notes.  I know the release notes are long, with lots
		of stuff most people don't care about, but I really would
		recommend reading them before installing...

	I did look at the release notes, albeit casually.  When I had
	the problem, I looked at them again.  This time I just looked
	at the Contents under things like "Error Recovery,"The Interrupt/Error
	Menu," etc. I was hoping to find some reference to sash and symmon.
	Do you know where these things are?  Under "Installing the Kernel
	Debugger."  Initially, when I looked at the 4D1-3.3.1 MR and INE,
	I'm sure I saw "Installing the Kernel Debugger" and skipped over
	to the next section.  You know, that's a particular piece of software.
	I don't use it; I don't care if it's installed or not; blah, blah.
	Now I'm not saying that that's right, but I don't think it's that
	unusual of a thought process, either.  Besides, why is sash in there?
	What's it got to do ( directly ) with kernel debugging?  Say
	symmon wasn't installed initially so I only get the INTERRUPT/ERROR
	for sash.  Why should I know to look under "Installing the Kernel
	Debugger" for it?  It would be better, IMHO, to mention potential
	problems under the appropriate header ( e.g., "Installing the Kernel
	Debugger" for symmon ) and under a COMMON PROBLEMS header.  You know,
	forward and backward references.
	
	Thanks to everyone for your help,

	bill ( a lazy sod, who doesn't read everything word for word,
	       and likes to shoot from the hip. )