Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!mimsy!umd5!decuac!felix!zemon
From: gor...@prls.UUCP (Gordon Vickers)
Newsgroups: comp.unix.ultrix
Subject: summary - 2.0 instal/use problems
Message-ID: <9986@felix.UUCP>
Date: Tue, 20-Oct-87 17:54:18 EDT
Article-I.D.: felix.9986
Posted: Tue Oct 20 17:54:18 1987
Date-Received: Sat, 24-Oct-87 06:49:05 EDT
Sender: ze...@felix.UUCP
Lines: 132
Approved: ze...@felix.UUCP
Reply-Path:
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
addresses.
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
about then.
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
pretty clear.]
* 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
big issue.]
* The only program we've had to recompile is "top" -- screen oriented
ps.
* Using the ibs parameter on a dd statement reading from a tmscp tape
drive can cause data corruption. Use "bs" instead. SPR filed:
ICA-9531.
* Good news: Section 2.2.7.5 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.
Mo Aidi
Nasa Ames Research Center
MS 233-9
Moffett Field, CA 94035
ARPA ADDRESS : a...@ames-pioneer.arpa or a...@128.102.19.9
----------------------------------------------------------------------------
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 =======================
{pyramid, philabs}!prls!gordon
----- ALL DISCLAIMERS APPLY. In fact I have sent this whole mess by mistake.