Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
From: gor...@prls.UUCP (Gordon Vickers)
Subject: summary - 2.0 instal/use problems
Date: Tue, 20-Oct-87 17:54:18 EDT
Posted: Tue Oct 20 17:54:18 1987
Date-Received: Sat, 24-Oct-87 06:49:05 EDT
Sorry I've taken so long to produce this 'summary' of
Ultrix 2.0 installation/use problems but I kept hoping
for more responces. Since I only received two responces,
I've included them in their entirety.
>From pyramid!hplabs!felix!decuac!prcrs!nes Thu Oct 1 12:01:05 1987
We've just started getting the info-ultrix items,
and it sounds as if there are problems that we don't
know we have. On the other hand, our experience with
2.0 has been relatively benign. We did have the
documentation (from the VAX 11/785 kit) about a month
before we got the TK-50 distribution for the MicroVAXen,
so we had plenty of time to go through the release notes
and the installation guides.
We have installed 2.0 on 3 MicroVAX II's. One is
configured with an RA60, 3 RA81's, and a TU81+. The
others are the small boxes with 3 RD54's each. The
first installation put / and /usr onto a spare RA60
pack, so we were able to finesse the problem of the
installation trashing the system disk. The 2.0
installation dealt well with different machine config-
urations, including finding multiplexors at non-standard
We haven't put 2.0 on the 785 yet, but not because of
problems with the operating system. We're a DEC OEM, and
the 785 is the main machine used to support our customer
sites. We're currently developing a plan to convert the
customers' MicroVAXes to 2.0 (the TU81+ and *much faster*
TK-50 may be reason enough), and the 785 will be upgraded
Anyway, here's my record of what we've run into so
far -- everything from trivial to serious. The order
is close to chronological.
* Trying to install *all* the unsupported subsets on an RD53 based system
will fill up the c. 40 meg. ra0g. [That should have been clear from
the documentation, but what the hey... It was a test installation
using one of the smaller systems.]
* The file /.rhosts needs to be added to the the Table of "Site-Specific
Files You Might Want to Save". [We've also got things in /usr/local
and /usr/lib/tabset. We kept a backup copy of the 1.2 root and /usr
file systems on line for at least a month after the conversion - nice
to have the luxury of enough space to make up for paranoia.]
* We'd been using the convention "netnumber.hostnumber" in /etc/hosts
and were a little concerned when the netsetup script changed the
numbers to "netnumber.0.0.hostnumber". The Network Management Guide,
though, has a good discussion of network addressing that explained all
this to us network novices.
* Don't use "Ultrix" in /etc/motd if you don't change the way
/etc/rc.local puts the kernel info into /etc/motd. [The infamous
line-eater seemed to be munching /etc/motd. Once we remembered what
was in the missing line -- "Welcome to Ultrix 2.0..." -- the fix was
* 2.0 rdump will not talk to 1.2 rdump. [This meant we couldn't use the
785's 9-track tape drive as we'd been doing in the past. On the
other hand, 2.0 makes the TK-50 a usable backup device *and* supports
the TU81+ that we have on one of the MicroVAXes, so this hasn't been a
* The only program we've had to recompile is "top" -- screen oriented
* Using the ibs parameter on a dd statement reading from a tmscp tape
drive can cause data corruption. Use "bs" instead. SPR filed:
* Good news: Section 18.104.22.168 of the Release notes said there was
a problem with the sh's pwd. This doesn't seem to be reproducible by
us or Atlanta CSC.
* By default, accounting is on -- change /etc/rc to save space or
invoke /etc/sa from crontab.
* The 9/22 message from Mo Aidi@Ames on restore not being able to
deal with multi-volume dumps is a concern, since being able to write
a sequence of dumps without worrying about tape boundaries has seemed
to be one of 2.0's big wins. I had no problem restoring the last
file from a dump that spanned TK-50's, and was able to restore
a 30meg. file system that I dumped to two short tapes at 1600 bpi.
We'll be interested in more details on the problem.
-Nancy Shoemaker PRC Realty Systems
...decuac!prcrs!nes 1500 Planning Research Dr.
>From pyramid!hplabs!a...@ames-pioneer.arpa Fri Sep 25 12:46:31 1987
I recently sent a mail to the ultrix-info group asking
for help for some problem we had with ultrix 2.0 end of the
tape. I would like to mention it here again that there is a
problem in writing to the tape in ultrix 2.0 DEC has done
something to the backup, tar and dump that supposed to enable
multivolume write to the tape, but when you want to restore it
from the the tape, it does not recognize the end of the tape and
it fails. The restore works fine with the files written with
prevoius version of ultrix.
Another problem we had was due to the NFS and mail . It seems
that when NFS and yellow pages get access the password file, it
keeps trying for ever and will not give up, and somehow mail could
not deliver or write to the /tmp while we were in the editing mode
in the mail (~v in the mail).
I would like to have a summary of your report when is completed.
Nasa Ames Research Center
Moffett Field, CA 94035
ARPA ADDRESS : a...@ames-pioneer.arpa or a...@22.214.171.124
Gordon P. Vickers, (408) 991-5370, =======================
Signetics Corp. || Ultrix-32 ver 1.2 ||
PO Box 3409 M/S 69 || VAX 11/750 ||
Sunnyvale, California, USA 94086 =======================
----- ALL DISCLAIMERS APPLY. In fact I have sent this whole mess by mistake.
USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.
SCO Files Lawsuit Against IBM
March 7, 2003 - The SCO Group filed legal action against IBM in the State
Court of Utah for trade secrets misappropriation, tortious interference,
unfair competition and breach of contract. The complaint alleges that IBM
made concentrated efforts to improperly destroy the economic value of
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services
business. See SCO vs IBM.
The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
Electronic mail: WorldWideWeb: