[comp.unix.ultrix] summary - 2.0 instal/use problems

gordon@prls.UUCP (Gordon Vickers) (10/21/87)

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!aidi@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 : aidi@ames-pioneer.arpa  or aidi@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.