jng@sli.com (Mike Gilbert) (04/26/89)
Summary:
HELP! My 3/60 SunOS 4.0.1 diskless client won't run, apparently because
the /var/tmp filesystem is NFS mounted on a 3/60 running SunOS 3.5!
What's the file /var/tmp/vm_fonts-n0, a temp file created by Sunview under
SunOS 4.0.1, and why can't it be located on an NFS filesystem running
SunOS 3.5? (This one file is my only problem!)
Background:
I just bought a Sun 3/60, and I need to run SunOS 4.0.1 on it as a
diskless client.
The only Sun system here with lots of free disk space is a 3/60 server
that has to keep running SunOS 3.5 for about 6 more months, because some
of my applications haven't been converted to SunOS 4.0 yet.
Because of the disk space situation, I need my new 3/60's root, swap, and
/usr partitions to be NFS mounted from my old SunOS 3.5 3/60.
But wait! What about the bootparamd issue? Well, I've got a third little
system on my network running bootparamd, so my new 3/60 client gets told
to look to the 3.5-based server for all its files.
In fact, I've got the diskless client all set up up and running just fine,
except for one little problem that I'm desperate for help with:
When I try to run SunView on my new 3/60 (the diskless 4.0.1 client of
the 3.5 server), SunView dumps core! Everything else on the system,
including all other windowing programs, work fine!
To track down this problem, I borrowed a shoebox from my friendly local
Sun sales rep who just sold me the 3/60. Using that to try all
combinations of local and NFS-mounted partitions, I tracked the problem
down as follows:
1. If /var/tmp is local or mounted NFS on a SunOS 4.0.1 server, then
SunView creates a reasonably large file called /var/tmp/vm_fonts-n0 and
runs fine.
2. If /var/tmp is mounted NFS on a SunOS 3.5 server (what I need to do),
then SunView creates a zero-length version of /var/tmp/vm_fonts-n0 and
crashes with a core dump. NOT GOOD!
3. If /var/tmp DOES NOT EXIST (obviously not a viable long-term solution,
but an interesting experiment), then SunView gives some message about
being unable to open something as it's coming up, but then it PROCEEDS TO
COME UP AND RUN FINE!
I'm desperate for a patch or workaround for this problem before my Sun
sales rep takes back his shoebox!
Questions:
1. How could the server's NFS version make a difference? I thought NFS
was a standard? Is there some difference between 3.5's and 4.0.1's NFS
that would explain this? If so, is a patch available for SunOS 3.5 to do
the same thing?
2. What is /var/tmp/vm_fonts-n0, anyway? I couldn't find it in any of
the SunView manuals. Is it virtual memory for the window system, as its
name implies? If I upgraded my 4MB system to 8MB, would SunView no longer
need to create this file?
3. Is this file /var/tmp/vm_fonts-n0 really optional, as my experiment #3
above would seem to indicate? SunView seems to work without it, but what
are the bad consequences if SunView can't create it? Is there any way I
can turn off whatever feature this is?
Please e-mail whatever guidance you can give me ASAP, and I'll summarize
if I find out anything.
Mike Gilbert INTERNET: jng%sli@uunet.uu.net
Software Leverage, Inc. USENET: ...uunet!sli!jng
(617)648-1414jonab@nisd.cam.unisys.com (Jonathan P. Biggar) (05/09/89)
> 2. What is /var/tmp/vm_fonts-n0, anyway?
I looked in our 4.0 sun sources and found out that this file is used as a
shared memory resource to share loaded fonts between sunview applications.
There must be some funny interaction between the shared memory support in
4.0.1 and the older 3.5 nfs that causes suntools to core dump.
Jon Biggar
jonab@nisd.cam.unisys.com