setup.txt

      Installing and Operating 4.3BSD-Quasijarus UNIX*
                        on the VAX|
                     November 18, 2003


                     Michael J. Karels

                        Chris Torek

                       James M. Bloom

                   Marshall Kirk McKusick

                     Samuel J. Leffler

                       William N. Joy

              Computer Systems Research Group
 Department of Electrical Engineering and Computer Science
             University of California, Berkeley
                Berkeley, California  94720
                       (415) 642-7780


                      Michael Sokolov

                     Quasijarus Project
          International Free Computing Task Force
           http://ifctfvax.Harhan.ORG/Quasijarus/


                          ABSTRACT


          This document contains instructions  for  the
     installation   and   operation   of   the  4.3BSD-
     Quasijarus release of the VAX UNIX system, as dis-
     tributed by Quasijarus Consortium.

          It discusses procedures for  installing  UNIX
     on a new VAX, and for upgrading an existing 4.2BSD
     or 4.3BSD VAX UNIX system to the new release.   An
     explanation  of  how  to  lay  out file systems on
     available disks, how to set up terminal lines  and
     user  accounts,  and  how  to  do  system-specific

*UNIX is a register trademark of AT&T in  the  USA  and
other countries.
+DEC, VAX, IDC, SBI, UNIBUS and MASSBUS are  trademarks
of Digital Equipment Corporation.




                      December 6, 2003





SMM:1-2lling and Operating 4.3BSD-Quasijarus UNIX on the VAX


     tailoring is provided.  A description  of  how  to
     install  and  configure  the networking facilities
     included  with  4.3BSD-Quasijarus   is   included.
     Finally,  the  document  details  system operation
     procedures: shutdown and startup,  hardware  error
     reporting  and  diagnosis, file system backup pro-
     cedures, resource control, performance monitoring,
     and  procedures  for  recompiling and reinstalling
     system software.
















































                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX-3


                      1. INTRODUCTION



     This document  explains  how  to  install  the  4.3BSD-
Quasijarus  release  of the Berkeley version of UNIX for the
VAX on your system.  Because of the file system organization
used  in 4.3BSD-Quasijarus, if you are not currently running
4.2BSD or 4.3BSD you will have to do a full  bootstrap  from
the  distribution tape.  The procedure for performing a full
bootstrap is outlined in chapter 2.   The  process  includes
booting  standalone  utilities from tape to format a disk if
necessary, then to copy a small root filesystem image onto a
swap  area.   This  filesystem  is  then  booted and used to
extract a dump of a standard root filesystem.  Finally, that
root  filesystem  is booted, and the remainder of the system
binaries and sources are  read  from  the  archives  on  the
tape(s).

     The technique for upgrading a 4.2BSD or  4.3BSD  system
is  described  in  chapter  3  of this document.  As 4.3BSD-
Quasijarus is upward-compatible  with  4.2BSD,  the  upgrade
procedure  involves  extracting a new set of system binaries
onto new root and /usr filesystems.  The  sources  are  then
extracted, and local configuration files are merged into the
new system.  4.2BSD  and  4.3BSD  user  filesystems  may  be
upgraded  in  place,  and  4.2BSD and 4.3BSD binaries may be
used with 4.3BSD-Quasijarus in the course of the conversion.
It  is  desirable to recompile most local software after the
conversion,  as  there  are  many  changes  and  performance
improvements in the standard libraries.

1.1.  Hardware supported

     Note that some VAX models are identical  to  others  in
all  respects  except speed.  The VAX 8650 will be hereafter
referred to as a VAX 8600; likewise, the VAX  8250  will  be
referred  to as a VAX 8200, the VAX-11/785 as an 11/780, and
the 11/725 as an 11/730.  These names  are  sometimes  shor-
tened  to ``8600,'' ``8200,'' ``780,'' ``750,'' and ``730.''
MicroVAXen are often referred to by their CPU  board  names,
i.e., KA630 for MicroVAX II, KA650 for MicroVAX 3, and KA655
for MicroVAX 3+.

     This distribution can be booted  on  a  VAX  8600,  VAX
8200,   VAX-11/780,   VAX-11/750,  VAX-11/730,  or  MicroVAX
II/3/3+ cpu with at least 2 megabytes of memory, and any  of
the following disks:









                      December 6, 2003





SMM:1-4lling and Operating 4.3BSD-Quasijarus UNIX on the VAX




        DEC MASSBUS:            RM03, RM05, RM80, RP06, RP07
        EMULEX MASSBUS:         AMPEX Capricorn, 9300, CDC 9766, 9775,
                                FUJITSU 2351 Eagle, 2361*
        DEC UNIBUS:             RK07, RL02, RA??*, RC25
        EMULEX SC-21V, SC-31    AMPEX DM980, Capricorn, 9300,
           UNIBUS*:             CDC 9762, 9766, FUJITSU 160M, 330M
        EMULEX SC-31 UNIBUS*:   FUJITSU 2351 Eagle
        DEC IDC:                R80, RL02
        DEC BI:                 RA??*
        DEC QBUS:               RD53, RD54, RA??*, RF??*



     The tape drives supported by this distribution are:


        DEC MASSBUS:                 TE16, TU45, TU77, TU78
        EMULEX MASSBUS:              TC-7000
        DEC UNIBUS:                  TS11, TU80, TU81+
        EMULEX TC-11, AVIV UNIBUS:   KENNEDY 9300, STC, CIPHER
        TU45 UNIBUS:                 SI 9700
        DEC BI:                      TU81+
        DEC QBUS:                    TK50, TK70, TU80, TU81+



     The tapes and disks may be on any available  UNIBUS  or
MASSBUS adapter at any slot.

     This distribution does not support the DEC CI780 or the
HSC50  disk controller.  As such, this distribution will not
boot on the standard VAX 8600 cluster  configurations.   You
will  need  to  configure  your  system  to use only UNIBUS,
MASSBUS, and BI bus disk and  tape  devices.   In  addition,
only  9-track  (TU81) tapes are supported on VAXBI, TK50 and
TK70 are not.  BI Ethernet and terminal controllers are  not
supported  either,  for  this  reason,  although  it  can be

* Other compatible UNIBUS controllers and drives may be
easily  usable  with  the system, but may require minor
modifications to the  system  to  allow  bootstrapping.
The EMULEX disk and SI tape controllers, and the drives
shown here are known  to  work  as  bootstrap  devices.
Known  RA  drives  are  RA60,  RA7[0123], RA8[012], and
RA9[02].  Known RF drives are RF3[0156] and  RF7[1234].
Other  SMD and MSCP drives may be used once pack labels
are written, but bootstrapping will be a problem  since
the  procedure  currently  relies  on  compiled-in disk
tables.
+ The TU81 support is untested but is identical to  the
TK50 code.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX-5


bootstrapped, a VAX 8200 without a UNIBUS would not be  very
useful.

1.2.  Distribution format

     The basic distribution is available  in  the  following
formats:

        *   1600bpi 9-track 2400' magnetic tapes (2)
        *   6250bpi 9-track 2400' magnetic tape (1)
        *   TK50 tape cartridge (1)

The following console media are available for VAX processors
that use them:

        *   RX01 console floppy disk for 11/780
        *   TU58 console cassette for 11/750 and 11/730
        *   RX50 console floppy disk for 8200
        *   RL02 console pack for 8600

Installation on any machine requires a tape unit. Since cer-
tain standard VAX packages do not include a tape drive, this
means one must either borrow one from another VAX system  or
one must be purchased separately.  The console media distri-
buted with the system are not suitable  for  use  as  opera-
tional  console media for 11/780, 11/730 and 8600 processors
because they do not contain CPU microcode or front end  pro-
cessor code.  Their intended use is only for installation.

     The distribution does not fit on several  standard  VAX
configurations  that  contain  only  small  disks.  If  your
hardware configuration does not provide at  least  75  Mega-
bytes  of disk space you can still install the distribution,
but you will probably have to operate without source for the
user  level  commands  and,  possibly,  the  source  for the
operating system.  The RK07-only  distribution  format  once
provided  by  our group is no longer available.  Further, no
attempt has ever been made to  install  the  system  on  the
standard  VAX-11/730  hardware  configuration  from DEC that
contains only dual RL02 disk drives (though the distribution
tape may be bootstrapped on an RL211 controller and the sys-
tem provides support for RL02 disk drives either on  an  IDC
or  an  RL211).  The labels on the distribution tape(s) show
the amount of disk space  each  tape  file  occupies,  these
should  be  used in selecting file system layouts on systems
with little disk space.

     If you have the facilities, it is a good idea  to  copy
the  magnetic  tape(s)  in  the  distribution  kit  to guard
against disaster.  The tapes contain some  512-byte  records
followed by many 10240-byte records.  There are interspersed
tape marks; end-of-tape is signaled by a double end-of-file.
The  first  file on the tape contains preliminary bootstrap-
ping programs.  This is followed by a binary image  of  a  3



                      December 6, 2003





SMM:1-6lling and Operating 4.3BSD-Quasijarus UNIX on the VAX


megabyte ``mini root'' file system.  Following the mini root
file is a full dump of the root file system (see  dump(8)*).
Additional  files on the tape(s) contain tape archive images
(see tar(1)).  See Appendix A for a description of the  con-
tents and format of the tape(s).

1.3.  VAX hardware terminology

     This section gives a short discussion of  VAX  hardware
terminology to help you get your bearings.

     If you have MASSBUS disks and tapes it is necessary  to
know the MASSBUS that they are attached to, at least for the
purposes  of  bootstrapping  and  system  description.   The
MASSBUSes can have up to 8 devices attached to them.  A disk
counts as a device.  A tape formatter counts  as  a  device,
and  several tape drives may be attached to a formatter.  If
you have a separate MASSBUS adapter for a disk and one for a
tape  then  it  is conventional to put the disk as unit 0 on
the MASSBUS with the lowest ``TR'' number, and the tape for-
matter  as  unit  0  on  the next MASSBUS.  On a 11/780 this
would correspond to having the disk on ``mba0''  at  ``tr8''
and  the  tape  on  ``mba1''  at  ``tr9''.  Here the MASSBUS
adapter with the lowest TR number has been  called  ``mba0''
and the one with the next lowest number is called ``mba1''.

     To find out the MASSBUS that your tape and disk are  on
you  can  examine  the  cabling and the unit numbers or your
site maintenance guide.  Do not be fooled into thinking that
the  number  on  the  front  of  the  tape drive is a device
number; it is a slave number, one of several possible  tapes
on  the single tape formatter.  For bootstrapping, the slave
number must be 0.  The formatter unit number may be anything
distinct from the other numbers on the same MASSBUS, but you
must know what it is.

     The MASSBUS devices  are  known  by  several  different
names  by  DEC software and by UNIX.  At various times it is
necessary to know both names.  There is, of course, the name
of  the  device like ``RM03'' or ``RM80''; these are easy to
remember because they are printed on the front of  the  dev-
ice.  DEC also names devices based on the driver name in the
system using a convention  that  reflects  the  interconnect
topology of the machine.  The first letter of such a name is
a ``D'' for a disk, the second letter depends on the type of
the  drive,  ``DR''  for  RM03, RM05, and RM80's, ``DB'' for
RP06's.  The next letter is related to the interconnect; DEC
calls  the first MASSBUS or UNIBUS adapter ``A'', the second
``B'', etc.  Thus, ``DRA'' is  an  RM  drive  on  the  first
MASSBUS   adapter.   Finally,  the  name  ends  in  a  digit

* References of the form X(Y) mean the subsection named
X in section Y of the UNIX programmer's manual.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX-7


corresponding to the unit  number  for  the  device  on  the
MASSBUS:  e.g.,  ``DRA0'' is a disk at the first device slot
on the first MASSBUS adapter and is an RM disk.

1.4.  UNIX device naming

     UNIX has a set of names for devices which are different
from  the DEC software names for the devices.  The following
table lists both the DEC and UNIX names  for  the  supported
devices:


        Hardware              UNIX   DEC
        

        RM disks              hp     DR
        RP disks              hp     DB
        MASSBUS TE/TU tapes   ht     MT
        TU78 tape             mt     MF
        RK disks              hk     DM
        RL disks              rl     DL
        TS tapes              ts     MS
        UDA disks             ra     DU
        RC25 disks            ra     DU
        IDC disks             rb     DQ
        UNIBUS SMD disks      up
        TM tapes              tm
        TMSCP tapes           tms    MU
        UNIBUS TU tapes       ut
        BI KDB disks          kra    DU


Here UNIBUS SMD disks are  disks  on  an  RM-emulating  con-
troller  on  the  UNIBUS,  and  TM tapes are tapes on a con-
troller that emulates the DEC TM11.   UNIBUS  TU  tapes  are
tapes  on  a  UNIBUS  controller that emulates the DEC TU45.
IDC disks are disks on an 11/730 Integral  Disk  Controller.
TS  tapes  are tapes on a controller compatible with the DEC
TS11 (e.g.  a TU80).  TMSCP tapes include the TU81 and TK50.

     The normal standalone system,  used  to  bootstrap  the
full UNIX system, uses device names:

        xx(a,c,d,p)

where xx is any of the UNIX device names in the table above.
The  parameters a, c, and d are the adapter, controller, and
drive numbers respectively.  The adapter is the index number
of the MASSBUS or UNIBUS (with the first one found as number
0).  The controller (or  ``device'')  number  is  the  index
number  of  the device on that adapter.  The drive number is
the index of the disk drive  on  that  controller  (or,  for
MASSBUS  tapes,  of  the  formatter).  The p value is inter-
preted differently for tapes and disks: for disks  it  is  a
disk  partition  (in  the range 0-7); for tapes it is a file



                      December 6, 2003





SMM:1-8lling and Operating 4.3BSD-Quasijarus UNIX on the VAX


number on the tape.* For example, partition 7 of drive 2  on
an  RA81  connected  to  the only UDA50 on UNIBUS 1 would be
``ra(1,0,2,7)''.  Normally, the adapter and controller  will
both  be  0;  it  may  therefore  be omitted from the device
specification, and most of the examples in this document  do
so.   When not running standalone, this partition would nor-
mally  be  available  as  ``/dev/ra2g''.   Here  the  prefix
``/dev''  is  the  name of the directory where all ``special
files'' normally live, the ``ra'' serves  the  obvious  pur-
pose,  the  ``2'' identifies this as a partition of hp drive
number ``2'' and the ``g'' identifies this  as  the  seventh
partition.

     On the VAX 8200, the adapter numbering is controlled by
the  ordering  of the nodes on the BI; the BI is probed from
low node numbers towards high.  Hence if there are two KDB50
adapters,  one at node 4, and one at node 7, the one at node
4 is kdb0, and the one at node 7 is kdb1.  The numbering for
UNIBUS  adapters works similarly.  Usually, the first UNIBUS
on an 8200 is at node 0; you will need this node  number  to
boot from tape.  Although DEC apparently doesn't want you to
know this, BI KLESI (TU81 controller) is actually  a  UNIBUS
adapter  with a UNIBUS KLESI behind it.  Unlike DEC software
UNIX treats it as a regular UNIBUS adapter, and it  must  be
taken into account when counting UNIBUS adapters.  Other VAX
models do not permit such chaotic ordering of adapters.

     In all simple cases, where only a single controller  is
present, a drive with unit number 0 (in its unit plug on the
front of the drive) will be called unit 0 in its  UNIX  file
name.   This  is not, however, strictly necessary, since the
system has a level of indirection in this naming.  If  there
are  multiple  controllers,  the disk unit numbers will nor-
mally be counted sequentially across controllers.  This  can
be  taken  advantage of to make the system less dependent on
the interconnect topology, and to make reconfiguration after
hardware failure extremely easy.

     Each UNIX physical disk is divided into at most 8 logi-
cal  disk  partitions, each of which may occupy any consecu-
tive cylinder range on the physical device.   The  cylinders
occupied  by the 8 partitions for each drive type are speci-
fied initially in the  disk  description  file  /etc/disktab
(c.f.   disktab(5)).  The partition information and descrip-
tion of the drive geometry are written in the  first  sector
of  each disk with the disklabel(8) program; currently, this
is possible on hp and ra disks, but not on the  other  types
of  disks on the VAX.  Each partition may be used for either

* Note that while a tape file consists of a single data
stream,  the  distribution tape(s) have data structures
in these files.  Although the tape(s)  contain  only  6
tape files, they comprise several thousand UNIX files.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX-9


a raw data area such as a paging area or  to  store  a  UNIX
file  system.  It is conventional for the first partition on
a disk to be used to store a root file  system,  from  which
UNIX  may  be  bootstrapped.  The second partition is tradi-
tionally used as a paging area, and the rest of the disk  is
divided  into spaces for additional ``mounted file systems''
by use of one or more additional partitions.

     The third logical partition of each physical disk  also
has  a  conventional  usage:  it allows access to the entire
physical device, in many cases including bad sector forward-
ing  information  recorded at the end of the disk (one track
plus 126 sectors).  It is occasionally used to store a  sin-
gle large file system or to access the entire pack when mak-
ing a copy of it on another.  Care must be  taken  if  using
this  partition  not  to  overwrite  the last few tracks and
thereby clobber the bad sector information.  Note  that  the
sector containing the disk label is normally write-protected
so that it is not  accidentally  overwritten.   Pack-to-pack
copies  should normally skip the first 16 sectors of a pack,
which contain the label and the initial bootstrap  for  some
processors.

1.5.  UNIX devices: block and raw

     UNIX makes a distinction between ``block'' and  ``raw''
(character) devices.  Each disk has a block device interface
where the system makes the device byte addressable  and  you
can write a single byte in the middle of the disk.  The sys-
tem will read out the data from the disk sector, insert  the
byte  you gave it and put the modified data back.  The disks
with the names ``/dev/xx0a'', etc are block devices.   There
are  also  raw  devices  available.   These  have names like
``/dev/rxx0a'', the ``r'' here standing  for  ``raw''.   Raw
devices bypass the buffer cache and use DMA directly to/from
the program's I/O buffers; they are normally  restricted  to
full-sector  transfers.  In the bootstrap procedures we will
often suggest using the raw devices, because these  tend  to
work  faster.  Raw devices are used when making new filesys-
tems, when checking unmounted filesystems,  or  for  copying
quiescent  filesystems.  The block devices are used to mount
file systems, or when operating on a mounted filesystem such
as the root.

     You should be aware  that  it  is  sometimes  important
whether  to use the character device (for efficiency) or not
(because it wouldn't work, e.g. to write a  single  byte  in
the  middle  of a sector).  Don't change the instructions by
using the wrong type of device indiscriminately.








                      December 6, 2003





SMM:1-10ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


                   2. BOOTSTRAP PROCEDURE



     This section explains the bootstrap procedure that  can
be  used  to  get the kernel supplied with this distribution
running on your machine.  If you are not  currently  running
4.2BSD  or  4.3BSD  you  will  have  to do a full bootstrap.
Chapter 3 describes how to upgrade  an  existing  4.2BSD  or
4.3BSD  system.   programs.   An understanding of the opera-
tions used in a full bootstrap is very helpful in performing
an  upgrade as well.  In either case, it is highly desirable
to read and understand the remainder of this document before
proceeding.

2.1.  Converting pre-4.2BSD Systems

     The file system format was  changed  between  3BSD  and
4.0BSD,  and  again between 4.1BSD and 4.2BSD.  At a minimum
you will have to dump any old file systems, and then restore
them  onto the 4.3BSD-Quasijarus file system.  Sites running
3BSD or 32/V may be able to modify the  restore  program  to
understand  the old 512 byte block file system, but this has
never been tried.  The dump format used in 4.0BSD and 4.1BSD
is  backward-compatible  with that used in 4.3BSD-Quasijarus
(which is unchanged from  4.2BSD).   That  is,  the  4.3BSD-
Quasijarus  restore  program  understands how to read 4.0BSD
and 4.1BSD dump tapes, although 4.3BSD-Quasijarus dump tapes
cannot  be  restored  under  4.0BSD  or  4.1BSD.  It is also
desirable to make a convenient copy of system  configuration
files  for use as guides when setting up the new system; the
list of files to save from 4.2BSD systems in chapter  3  may
be used as a guideline.

     The first step  is  to  dump  your  file  systems  with
dump(8).   For  the  utmost of safety this should be done to
magtape.  However, if you enjoy gambling with your life  (or
you have a VERY friendly user community) and you have enough
disk space, you can try converting your file  systems  while
copying to a new disk partition by piping the output of dump
directly into restore after bringing  up  4.3BSD-Quasijarus.
If  you select the latter tack, a version of the 4.1BSD dump
program that runs under  4.3BSD-Quasijarus  is  provided  in
/etc/dump.4.1.   Beware  that  file  systems  created  under
4.3BSD-Quasijarus can use about 5-10% more  disk  space  for
file  system  related  information than under 4.1BSD.  Thus,
before dumping each file system it is a good idea to  remove
any  files  that  may be easily regenerated.  Since all pro-
grams should be recompiled under the new system,  your  best
bet  is  to  remove  any object files.  File systems with at
least  10%  free  space  on  them  should  restore  into  an
equivalently  sized  4.3BSD-Quasijarus  file  system without
problem.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX11


2.2.  Booting from tape

     The tape bootstrap procedure used to create  a  working
system involves the following major steps:

1)   Format a disk pack with the format program.

2)   Copy a ``mini root'' file system from the tape onto the
     swap area of the disk.

3)   Boot the UNIX system on the ``mini root''.

4)   Restore the full root file system using restore(8).

5)   Build a console floppy,  cassette,  or  RL02  pack  for
     bootstrapping.

6)   Reboot the completed root file system.

7)   Label the disks with the disklabel(8) program.

8)   Build and restore the /usr file system from  tape  with
     tar(1).

9)   Extract the system and utility  files  and  contributed
     software as desired.

     Certain of these steps are dependent on  your  hardware
configuration.   Formatting  the disk pack used for the root
file system may require using the  DEC  standard  formatting
programs.   Also,  if you are bootstrapping the system on an
11/750, no console cassette is usually required.

     Bootstrapping an 8600 is  a  bit  more  difficult  than
bootstrapping  the other machines.  The procedures for load-
ing the toggle program and reading the tape bootstrap  moni-
tor  described in Appendix B must be used if you do not have
access to a console RL02 pack with a UNIX bootstrap.  Such a
pack  may  be  made  on  an 8600 already running UNIX, or on
another 4.3BSD-Quasijarus system with an  RL02  drive  using
the  procedures  in 4.1.1.  One may be required to enter the
toggle program more than once.  After the bootstrap  monitor
is  loaded,  device  addresses  will  be  the same as if the
machine were an 11/780.  UNIBUS  and  MASSBUS  adaptors  are
numbered from zero across both SBIA's (if present).

     The following sections  describe  the  above  steps  in
detail.   In these sections references to disk drives are of
the form xx(n,m) and references to files on tape drives  are
of  the  form yy(n,m) where xx and yy are names described in
section 1.4 and n and m are  the  unit  and  offset  numbers
described in section 1.4.  Commands you are expected to type
are shown in italics, while that information printed by  the
system   is   shown  emboldened.   These  instructions  were



                      December 6, 2003





SMM:1-12ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


originally written for large VAXen that use  console  media.
MicroVAXen have no console media, if you are bootstrapping a
MicroVAX, see Appendix B.

     Throughout the installation steps the reboot switch  on
a 780 or 730 should be set to off; on an 8600 or 750 set the
power-on action to halt.  (In normal operation a 780 or  730
will  have the reboot switch on and an 8600 or 750 will have
the power-on action set to reboot/restart.) On an  8200  the
keyswitches should be set to Enable/Update for bootstrapping
and maintenance (Secure/Autostart in normal operation); on a
MicroVAX  II  the  switch  on  the  rear I/O panel should be
turned up to enable halts  (halts  are  disabled  in  normal
operation).

     If you encounter problems while following the  instruc-
tions  in this part of the document, refer to Appendix C for
help in troubleshooting.

2.2.1.  Step 1: formatting the disk

     All disks used with 4.3BSD-Quasijarus should be format-
ted  to  insure  the proper handling of physically corrupted
disk sectors.  If you have DEC disk drives, you  should  use
the  standard  DEC  formatter to format your disks.  If not,
the format program included in the distribution, or a vendor
supplied  formatting  program,  may be used to format disks.
The format program is capable of formatting any of the  fol-
lowing supported distribution devices:


        EMULEX MASSBUS:        AMPEX Capricorn, 9300, CDC 9766, 9775,
                               FUJITSU 330M, 2351 Eagle
        EMULEX SC-21V, SC-31   AMPEX 9300, Capricorn, CDC 9730, 9766,
            UNIBUS:            FUJITSU 160M, 330M
        EMULEX SC-31 UNIBUS:   FUJITSU 2351 Eagle



     The format program is for hp/up SMD disks  only.   MSCP
disks  usually  do  not  require formatting.  If you need to
format an MSCP disk, you will need to use formatting  utili-
ties provided by the drive or controller vendor, format will
not help you.

     If you have run a pre-4.1BSD version  of  UNIX  on  the
packs you are planning to use for bootstrapping it is likely
that the bad sector information on the packs has  been  des-
troyed,  since  it was accessible as normal data in the last
several tracks of the disk.  You should  therefore  run  the
formatter again to make sure the information is valid.

     On an 11/750, to use a disk pack as a bootstrap device,
sectors 0 through 15, the disk sectors in the file ``/boot''



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX13


(the program that loads the system image), and the file sys-
tem indices that lead to this file must not have any errors.
On an 8600, 11/780,  or  11/730,  the  ``boot''  program  is
loaded  from  the console medium and includes device drivers
for the ``hp'' and ``up'' disks that do ECC  correction  and
bad  sector  forwarding; consequently, on these machines the
system may be bootstrapped on these disks even if  the  disk
is  not error free in critical locations. In general, if the
first 15884 sectors of your disk are clean you are safe;  if
not you can take your chances.

     To load the format  program,  insert  the  distribution
TU58 cassette or RX01 floppy disk in the appropriate console
device (on the 11/730 use cassette 0) and do  the  following
steps.

     If you have an 8600 and no RL02 pack  with  UNIX  stan-
dalone  programs  start the bootstrap monitor using the pro-
cedure described in Appendix B.  Then give the command:

        =format


     If you have an 11/780 give the commands:

        >>>HALT
        >>>UNJAM
        >>>INIT
        >>>LOAD FORMAT
        >>>START 2


     If you have an 11/750 give the commands:

        >>>I
        >>>B DDA0
        =format


     If you have an 11/730 give the commands:

        >>>H
        >>>I
        >>>L DD0:FORMAT
        >>>S 2


     The format program should now be running  and  awaiting
your input:

        Disk format/check utility

        Enable debugging (1=bse, 2=ecc, 3=bse+ecc)?




                      December 6, 2003





SMM:1-14ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


     If you made a mistake loading the program off the  TU58
cassette  or using the bootstrap monitor loaded for the 8600
the ``='' prompt should reappear and you can retype the pro-
gram  name.   If something else happened, you may have a bad
distribution cassette or floppy, or  your  hardware  may  be
broken; refer to Appendix C for help in troubleshooting.  If
you are unable to load programs off the distributed  console
medium,  consult  Appendix B for an alternate (more painful)
approach.

     Format  will  create  sector  headers  and  verify  the
integrity  of  each  sector formatted.  Remember format runs
only on the up and  hp  drives  listed  above.  Format  will
prompt  for  the information required as shown below.  Ques-
tions with  default  answers  appear  with  the  default  in
parentheses  at  the prompt; a carriage return will take the
default.  If you  err  in  answering  questions,  ``Delete''
erases  the  last  character  typed,  and  ``^U'' erases the
current input line.

        Enable debugging (0=none, 1=bse, 2=ecc, 3=bse+ecc)? 0
        Device to format? xx(0,0)
         ...(the old bad sector table is read; ignore any errors that occur here)...
        Formatting drive xx0 on adaptor 0: verify (yes/no)? yes
        Device data: #cylinders=842, #tracks=20, #sectors=48
        Starting cylinder (0):(hit RETURN to accept the defaults)
        Starting track (0):
        Ending cylinder (841):
        Ending track (19):
        Available test patterns are:
                  1 - (f00f) RH750 worst case
                  2 - (ec6d) media worst case
                  3 - (a5a5) alternating 1's and 0's
                  4 - (ffff) Severe burnin (up to 48 passes)
        Pattern (one of the above, other to restart)? 2
        Maximum number of bit errors to allow for soft ECC (3):
        Start formatting...make sure the drive is online
         ...(soft ecc's and other errors are reported as they occur)...
         ...(if 4 write check errors were found, the program terminates like this)...
        Errors:
        Bad sector: 0
        Write check: 4
        Hard ECC: 0
        Other hard: 0
        Marked bad: 0
        Skipped: 0
        Total of 4 hard errors revectored.
        Writing bad sector table at block 524256
         ...(524256 is the block # of the first block in the bad sector table)...
        Done

Once the root device has been formatted, format will  prompt
for  another  disk  to  format.   Halt the machine by typing
``control-P'' and ``H'' (the ``H'' is necessary only on  the



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX15


780 and 8600, but does not hurt on the other machines).

        Enable debugging (1=bse, 2=ecc, 3=bse+ecc)?^P
        >>>H


     It may be necessary to format other drives before  con-
structing  file systems on them; this can be done at a later
time with the steps just performed.  Format can also be used
in an extended test mode (pattern 4) that uses numerous test
patterns in up to 48 passes to detect as many  disk  surface
errors  as  possible;  this  test may be run for many hours,
depending on the CPU and controller.  On an 11/780, this can
be  sped up significantly by setting the clock fast.  It may
be run for some number of passes, then either terminated  or
continued according to the errors found to that point.

2.2.2.  Step 2: copying the mini-root file system

     The second step is to run a simple program, copy, which
copies a small root file system into the second partition of
the disk.  This file system  will  serve  as  the  base  for
creating  the  actual  root file system to be restored.  The
version of the operating system maintained  on  the  ``mini-
root''  file  system  understands that it should not swap on
top of itself, thereby allowing double use of the disk  par-
tition.   Copy  is  loaded  just  as  the format program was
loaded; for example, if not using console  media,  one  must
enter  the  toggle and the bootstrap monitor as described in
Appendix B and then:


        (copy mini root file system)
        =copy
        From: yy(y,1)                        (unit y, second tape file)
        To: xx(x,1)                          (mini root is on drive x; second partition)
        Copy completed: 308 records copied
        From:


while for an 8200:


        (copy mini root file system)
        >>>B/R5:800 CSA1                     (or CSA2 if using the 2nd diskette slot)
        BOOT58>LOAD COPY
        BOOT58>START 2
        From: yy(y,1)                        (unit y, second tape file)
        To: xx(x,1)                          (mini root is on drive x; second partition)
        Copy completed: 308 records copied
        From:


for an 11/780:



                      December 6, 2003





SMM:1-16ling and Operating 4.3BSD-Quasijarus UNIX on the VAX




        (copy mini root file system)
        >>>LOAD COPY
        >>>START 2
        From: yy(y,1)                        (unit y, second tape file)
        To: xx(x,1)                          (mini root is on drive x; second partition)
        Copy completed: 308 records copied
        From:


for an 11/750:


        (copy mini root file system)
        >>>B DDA0
        =copy
        From: yy(y,1)                        (unit y, second tape file)
        To: xx(x,1)                          (mini root is on drive x; second partition)
        Copy completed: 308 records copied
        From:


and for an 11/730:


        (copy mini root file system)
        >>>L DD0:COPY
        >>>S 2
        From: yy(y,1)                        (unit y, second tape file)
        To: xx(x,1)                          (mini root is on drive x; second partition)
        Copy completed: 308 records copied
        From:

        (As above, `delete' erases characters and `^U' erases lines.)


2.2.3.  Step 3: booting from the mini-root file system

     You now have the minimal  set  of  tools  necessary  to
create  a  root file system and restore the file system con-
tents from tape.   To  access  this  file  system  load  the
bootstrap program and boot the version of unix that has been
placed in the ``mini-root'':

        (follow the procedure in Appendix B to load the bootstrap monitor)

        (load bootstrap program)
        =boot
        Boot
        : xx(x,1)vmunix            (bring in vmunix off mini root)


or, on an 8200:



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX17




        (load bootstrap program)
        >>>B/R5:800 CSA1           (or CSA2 if using the 2nd diskette slot)
        BOOT58>BOOT ANY
        Boot
        : xx(x,1)vmunix            (bring in vmunix off mini root)


or, on an 11/780:


        (load bootstrap program)
        >>>BOOT ANY
        Boot
        : xx(x,1)vmunix            (bring in vmunix off mini root)


or, on an 11/750:


        (load bootstrap program)
        >>>B DDA0
        =boot
        Boot
        : xx(x,1)vmunix            (bring in vmunix off mini root)


or, on an 11/730:


        (load bootstrap program)
        >>>L DD0:BOOT
        >>>D RB 3
        >>>S 2
        Boot
        : xx(x,1)vmunix            (bring in vmunix off mini root)

        (As above, `delete' erases characters and `^U' erases lines.)


The standalone boot program should then read the system from
the  mini  root file system you just created, and the system
should boot:

        271944+78848+92812 start 0x12e8
        4.3 BSD UNIX #1: Wed Apr  9 23:33:59 PST 1988
            karels@monet.berkeley.edu:/usr/src/sys/GENERIC
        real mem  = xxx
        avail mem = yyy
        ... information about available devices ...
        root device?





                      December 6, 2003





SMM:1-18ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


     The  first  three  numbers  are  printed  out  by   the
bootstrap  programs  and are the sizes of different parts of
the system (text, initialized and uninitialized data).   The
system  also  allocates several system data structures after
it starts running.  The sizes of these structures are  based
on  the  amount of available memory and the maximum count of
active users expected, as declared in a system configuration
description.  This will be discussed later.

     UNIX itself then runs for the first time and begins  by
printing out a banner identifying the release and version of
the system that is in use and the date that it was compiled.

     Next the mem messages give the amount of  real  (physi-
cal)  memory  and  the  memory available to user programs in
bytes.  For example, if your machine  has  16  megabytes  of
memory, xxx will be 16777216.

     The messages that come out next show what devices  were
found   on   the  current  processor.   These  messages  are
described in autoconf(4).  The distributed  system  may  not
have  found  all  the communications devices you have (dh's,
dz's, etc.), or all the mass storage  peripherals  you  have
especially  if you have more than two of anything.  You will
correct this soon, when you create  a  description  of  your
machine  from which to configure UNIX.  The messages printed
at boot here contain much of the information  that  will  be
used  in creating the configuration.  In a correctly config-
ured system most of the information present  in  the  confi-
guration description is printed out at boot time as the sys-
tem verifies that each device is present.

     The ``root device?'' prompt was printed by  the  system
and  is  now asking you for the name of the root file system
to use.  This happens because the distribution system  is  a
generic  system.   It can be bootstrapped on any VAX cpu and
with its root device and paging area on any  available  disk
drive.   You should respond to the root device question with
xx0*.  This response supplies  two  pieces  of  information:
first,  xx0  shows that the disk it is running on is drive 0
of type xx, secondly the ``*'' shows that the system is run-
ning  ``atop''  the  paging area.  The latter is most impor-
tant, otherwise the system will attempt to page  on  top  of
itself  and chaos will ensue.  You will later build a system
tailored to your configuration that will not ask this  ques-
tion when it is bootstrapped.

        root device? xx0*
        WARNING: preposterous time in file system -- CHECK AND RESET THE DATE!
        erase ^?, kill ^U, intr ^C
        #


     The ``erase ...'' message is part of /.profile that was



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX19


executed by the root shell when it started.  This message is
present to remind you that the line  character  erase,  line
erase,  and interrupt characters are set to be what is stan-
dard on DEC systems; this insures that things are consistent
with the DEC console interface characters.

2.2.4.  Step 4: restoring the root file system

     UNIX is now running, and the `UNIX Programmer's manual'
applies.  The `#' is the prompt from the shell, and lets you
know that you  are  the  super-user,  whose  login  name  is
``root''.   To complete installation of the bootstrap system
two steps remain.  First,  the  root  file  system  must  be
created,  and  second a boot floppy or cassette must be con-
structed.

     To create the root file system the shell script ``xtr''
should be run as follows:

        # disk=xx0  type=tt  tape=yy  xtr

where xx0 is the name of the disk on  which  the  root  file
system  is  to be restored (unit 0), tt is the type of drive
on which the root file system is to  be  restored  (see  the
table  below), and yy is the name of the tape drive on which
the distribution tape is mounted.

     If the root file system is to reside on  a  disk  other
than  unit 0 (as the information printed out during autocon-
figuration shows), you will have  to  create  the  necessary
special  files  in  /dev  and use the appropriate value. For
example, if the root should  be  placed  on  hp1,  you  must
create  /dev/rhp1a and /dev/hp1a using the MAKEDEV script in
/dev as follows:

        # cd /dev; MAKEDEV hp1

The following table lists the various drive types.


        Drive          Type           Drive          Type
        

        DEC RM03       type=rm03      DEC RM05       type=rm05
        DEC RM80       type=rm80      DEC RP06       type=rp06
        DEC RP07       type=rp07      DEC RK07       type=rk07
        DEC RA80       type=ra80      DEC RA60       type=ra60
        DEC RA81       type=ra81      DEC R80        type=rb80
        DEC RA70       type=ra70      DEC RA82       type=ra82
        DEC RD53       type=rd53      DEC RD54       type=rd54
        CDC 9766       type=9766      CDC 9775       type=9775
        AMPEX 300M     type=9300      AMPEX 330M     type=capricorn
        FUJITSU 160M   type=fuji160   FUJITSU 330M   type=capricorn
        FUJITSU 404M   type=eagle

                                   |
                                   |
                                   |
                                   |
                                   |
                                   |
                                   |
                                   |
                                   |
                                   |
                                   |
                                   |
                                   |

















                      December 6, 2003





SMM:1-20ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


This will generate many messages regarding the  construction
of the file system and the restoration of the tape contents,
but should eventually stop with the messages:

         ...
        Root filesystem extracted

        If this is an 8600, update the console RL02
        If this is a 780, update the floppy
        If this is a 730, update the cassette
        #


2.2.5.  Step 5: creating a boot floppy or cassette

     If the machine is an 8600, 8200, 11/780  or  11/730,  a
boot floppy, cassette, or console RL02 should be constructed
according to the instructions in chapter 4.   For  11/750's,
bootstrapping is normally performed by using a boot prom and
special code located in sectors 0-15 of the root  file  sys-
tem.   If  you do not have a boot prom for your system disk,
you may also create a TU58 cassette  with  BOOT58  and  UNIX
boot  program  and boot script and use it as your boot path.
If you want to pursue this approach, contact Quasijarus Con-
sortium  for  assistance.   VAX 8200 has a very similar boot
architecture to 11/750, except that the bootable disks  sup-
ported  by  the  ROM  are VAXBI and UNIBUS MSCP disks, i.e.,
KDB50 and UDA50, and the console medium for  BOOT58  is  not
TU58  but  RX50.   MicroVAXen  have  no console media.  They
instead have a special version of VMB in  the  ROM  and  may
only be booted via the bootblock on the disk.

     The disklabel program installs the 750/8200 and  Micro-
VAX  boot  code  along with the pack label.  Locate the disk
name and type from the table in step 7, then run the follow-
ing command:

        # disklabel -rw ${disk}0 $type "optional pack name"

All MicroVAXen must use the rdboot primary bootblock regard-
less  of the disk type.  It is the only bootblock for Micro-
VAXen, all other bootblocks are for 750 and  8200.   If  you
have  a MicroVAX and your disk is something other than RDxx,
you must explicitly specify the rdboot primary bootblock  on
the  disklabel  command line.  If you are booting from UDA50
or some other UNIBUS MSCP disk on an 8200, the  raboot  pri-
mary  bootblock  may  not  correctly  communicate the UNIBUS
adapter number to the secondary bootblock.  It computes  the
correct  uba  number  for 750, but this computation probably
won't be correct on an 8200.  You will need to either  patch
the bootblock or use a BOOT58-based boot path.

     On  an  11/780  with  old-style  (MS780C)   interleaved
memory,  or  other configurations that require alteration of



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX21


the standard boot files, this step may be left for later.

2.2.6.  Step 6: rebooting the completed root file system

     With the above work completed, all that is left  is  to
reboot:

        #sync                              (synchronize file system state)
        #^P                                (halt machine)
        >>>HALT                            (for 11/780's)
        >>>UNJAM                           (for 8600's or 11/780's only)
        >>>I                               (initialize processor state)
        >>>B xxS                           (on an 11/750, use B/2; see below for 8200)
        ...(boot program is eventually loaded)...
        Boot
        : xx(x,0)vmunix                    (vmunix brought in off root)
        271944+78848+92812 start 0x12e8
        4.3 BSD UNIX #1: Wed Apr  9 23:33:59 PST 1988
            karels@monet.berkeley.edu:/usr/src/sys/GENERIC
        real mem  = xxx
        avail mem = yyy
        ... information about available devices ...
        root on xx0
        WARNING: preposterous time in file system -- CHECK AND RESET THE DATE!
        erase ^?, kill ^U, intr ^C
        #



     On an 8200, or if the root device selected by the  ker-
nel is not correct, it is necessary to boot using the option
to ask for the root device.  On the 8200, use B/R5:800  fol-
lowed  by  @ANYBOO.CMD; on the 11/750, use B/3; on the other
processors, use BOOT ANY.  At the prompt from the bootstrap,
use  the  same  device  specification  above: xx(x,0)vmunix.
Then, to the question ``root device?,''  respond  with  xx0.
See section 6.1 and appendix C if the system does not reboot
properly.

     The system is now running single user on the  installed
root  file  system.   The next section tells how to complete
the installation of distributed software on  the  /usr  file
system.

2.2.7.  Step 7: placing labels on the disks

     First set up shell variables, so that the  commands  we
give  will  work regardless of the disk you have.  You might
wish to review the disk configuration information in section
4.3  before  continuing; the partitions used below are those
most appropriate in size.  Find the disk  you  have  in  the
following  table  and execute the commands in the right hand
portion of the table:




                      December 6, 2003





SMM:1-22ling and Operating 4.3BSD-Quasijarus UNIX on the VAX




        DEC RM03               # disk=hp; name=hp0g; type=rm03
        DEC RM05               # disk=hp; name=hp0g; type=rm05
        DEC RM80               # disk=hp; name=hp0g; type=rm80
        DEC RP06               # disk=hp; name=hp0g; type=rp06
        DEC RP07               # disk=hp; name=hp0h; type=rp07
        DEC RK07               # disk=hk; name=hk0g; type=rk07
        DEC RA60               # disk=ra; name=ra0h; type=ra60
        DEC RA70               # disk=ra; name=ra0h; type=ra70
        DEC RA80               # disk=ra; name=ra0h; type=ra80
        DEC RA81               # disk=ra; name=ra0h; type=ra81
        DEC RA82               # disk=ra; name=ra0h; type=ra82
        DEC R80                # disk=rb; name=rb0h; type=rb80
        UNIBUS CDC 9766        # disk=up; name=up0g; type=9766
        UNIBUS AMPEX 300M      # disk=up; name=up0g; type=9300
        UNIBUS AMPEX 330M      # disk=up; name=up0g; type=capricorn
        UNIBUS FUJITSU 160M    # disk=up; name=up0g; type=fuji160
        UNIBUS FUJITSU 330M    # disk=up; name=up0g; type=capricorn
        UNIBUS FUJITSU 404M    # disk=up; name=up0h; type=eagle
        MASSBUS CDC 9766       # disk=hp; name=hp0g; type=9766
        MASSBUS AMPEX 300M     # disk=hp; name=hp0g; type=9300
        MASSBUS AMPEX 330M     # disk=hp; name=hp0g; type=capricorn
        MASSBUS FUJITSU 330M   # disk=hp; name=hp0g; type=capricorn
        MASSBUS FUJITSU 404M   # disk=hp; name=hp0h; type=eagle


If you have a DEC RA disk, but it is on a  KDB50,  insert  a
`k':

        # disk=k$disk; name=k$name

Next find the tape you have in the following table and  exe-
cute the commands in the right hand portion of the table:


        DEC TE16/TU45/TU77        # cd /dev; MAKEDEV ht0; sync
        DEC TU78                  # cd /dev; MAKEDEV mt0; sync
        DEC TS11                  # cd /dev; MAKEDEV ts0; sync
        DEC TK50/TK70/TA80/TA81   # cd /dev; MAKEDEV tmscp0; sync
        EMULEX TC11               # cd /dev; MAKEDEV tm0; sync
        SI 9700                   # cd /dev; MAKEDEV ut0; sync



     On hp and ra disks  (excluding  those  on  the  KDB50),
4.3BSD-Quasijarus  uses  disk  labels in the first sector of
each disk to contain information about the geometry  of  the
drive and the partition layout.  This information is written
with disklabel(8).  To label the disk  containing  the  root
file system, run the following command:

        # disklabel -rw ${disk}0 $type "optional pack name"




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX23


This sets up the default partition table.  Type can  be  any
name  listed  in  /etc/disktab;  if you want something other
than the default tables, you can edit /etc/disktab and add a
new  name: e.g., ``ra81-local.''  Alternatively, you can use
the -e option to edit the label; you will have  to  set  the
``EDITOR'' environment variable to /bin/ed:

        # EDITOR=/bin/ed; export EDITOR


     You should label all your disks as  soon  as  possible,
but  you  must  label the root pack on a VAX-11/750, even if
labels are not supported (e.g., on ``up''  disks),  as  this
also  creates the boot block.  Boot blocks are also required
on MicroVAXen.  As a general rule, it is always safe to  run
disklabel: if labels are not supported on some disk, nothing
of consequence will happen.

2.2.8.  Step 8: setting up the /usr file system

     The next thing to do is to extract the rest of the data
from the tape:



        # date yyyymmddhhmm                (set date, see date(1))
        ....
        # passwd root                      (set password for super-user)
        New password:                      (password will not echo)
        Retype new password:
        # hostname mysitename              (set your hostname)
        # newfs ${name} ${type}            (create empty user file system)
        (this takes a few minutes)
        # mount /dev/${name} /usr          (mount the usr file system)
        # cd /usr                          (make /usr the current directory)
        # mt fsf
        # tar xpbf 20 /dev/rmt12           (extract all of usr except usr/src)
        (this takes about 15-20 minutes)


If the tape  had  been  rewound  or  positioned  incorrectly
before the tar, it may be repositioned by the following com-
mands.

        # mt rew
        # mt fsf 3

The data on the fourth tape file has now been extracted.  If
you are using 1600bpi tapes, the first reel of the distribu-
tion is no longer needed; the remainder of the  installation
procedure  uses  the  second  reel  of  tape  that should be
mounted in place of the first.  The first instruction  below
is  ignored  if  using 1600bpi tapes.  The installation pro-
cedure continues from this point on the  6250bpi  tape.   In



                      December 6, 2003





SMM:1-24ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


1600bpi  and  TK50  distribution  formats  the  sources  are
compressed with compress(1) in order to fit on the tape.  If
you  are  extracting  a  compressed distribution, modify the
following commands appropriately.


        # mt fsf                                      (do not do on 1600bpi tapes)
        # mkdir src                                   (make directory for source)
        # mkdir src/sys                               (make directory for system source)
        # cd src/sys                                  (make /usr/sys the current directory)
        # tar xpbf 20 /dev/rmt12                      (extract the system source)
        (this takes about 5-10 minutes)
        # cd /                                        (back to root)
        # chmod 755  /  /usr  /usr/src /usr/src/sys
        # rm -f sys
        # ln -s usr/src/sys sys                       (make a symbolic link to the system source)
        # umount /dev/${name}                         (unmount /usr)



     You can check the consistency of the /usr  file  system
by doing

        # fsck /dev/r${name}

The output from fsck should look something like:

        ** /dev/rxx0h
        ** Last Mounted on /usr
        ** Phase 1 - Check Blocks and Sizes
        ** Phase 2 - Check Pathnames
        ** Phase 3 - Check Connectivity
        ** Phase 4 - Check Reference Counts
        ** Phase 5 - Check Cyl groups
        671 files, 3497 used, 137067 free (75 frags, 34248 blocks)


     If there are inconsistencies in the  file  system,  you
may be prompted to apply corrective action; see the document
describing fsck for information.

     To use the /usr file system, you should now remount  it
by saying

        # /etc/mount /dev/${name} /usr

You can then  extract  the  source  code  for  the  commands
(except  on RK07's and RM03's this will fit in the /usr file
system):

        # cd /usr/src
        # mt fsf
        # tar xpb 20




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX25


If you get an error at this point,  most  likely  it  was  a
problem  with tape positioning.  You can reposition the tape
by rewinding it and then skipping  over  the  files  already
read (see mt(1)).

2.2.9.  Additional software

     There exists additional software that used to  be  dis-
tributed  with  the system.  Since it is static and does not
change with ongoing  Quasijarus  development,  it  has  been
separated  from the main 4.3BSD-Quasijarus distribution.  If
you want to install the 4.3BSD-*  software  supplement,  you
can obtain and install it separately.

2.3.  Additional conversion information

     After setting up the new 4.3BSD-Quasijarus filesystems,
you  may  restore  the  user  files  that were saved on tape
before beginning the  conversion.   Note  that  the  4.3BSD-
Quasijarus  restore  program does its work on a mounted file
system using normal system operations (unlike the older res-
tor  that  accessed the raw file system device and deposited
inodes in the appropriate locations on  disk).   This  means
that  file  system dumps may be restored even if the charac-
teristics of the file system changed.   To  restore  a  dump
tape for, say, the /a file system something like the follow-
ing would be used:

        # mkdir /a
        # disklabel -rw hp1 eagle
        # newfs hp1g
        # mount /dev/hp1g /a
        # cd /a
        # restore r

If you chose to convert 4.1BSD filesystems while copying  to
a  new  disk  area,  do  so by piping the output of dump.4.1
directly into restore after bringing up 4.3BSD-Quasijarus.

     If tar images were written instead of doing a dump, you
should  be sure to use the `p' option when reading the files
back.  No matter how you restore a file system, be sure  and
check its integrity with fsck when the job is complete.

     To convert a compiler from 4.1BSD to  4.3BSD-Quasijarus
you  should  simply have to recompile and relink the various
parts.  If the processor is written in itself, for  instance
a  PASCAL  compiler written in PASCAL, the important step in
converting is to save a working copy of  the  4.1BSD  binary
before converting to 4.3BSD-Quasijarus.  Then, once the sys-
tem has been changed over, the 4.1BSD binary should be  used
in the rebuilding process. To do this, you should enable the
4.1 compatibility option when you configure the kernel  (see
section 4.3).



                      December 6, 2003





SMM:1-26ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


     If no working 4.1BSD binary  exists,  or  the  language
processor uses some nonstandard system call, you will likely
have to compile the language processor into an  intermediate
form,  such  as  assembly language, on a 4.1BSD system, then
bring the intermediate form to 4.3BSD-Quasijarus for  assem-
bly and loading.



















































                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX27


           3. UPGRADING A 4.2BSD OR 4.3BSD SYSTEM



     This section describes the procedure  for  upgrading  a
4.2  or  4.3BSD system to 4.3BSD-Quasijarus.  This procedure
may vary according to the  version  of  the  system  running
before  conversion.  If you are upgrading from 4.2BSD, begin
by reading the ``Bugs Fixes and Changes in 4.3BSD'' document
to see what has changed since the last time you bootstrapped
the system.  If you have local system modifications  to  the
kernel  to  install,  look  at the document ``Changes to the
Kernel in 4.3BSD'' to get an idea of how the system  changes
will affect your local modifications.

     If you are running 4.2BSD  or  4.3BSD,  upgrading  your
system  involves replacing your kernel and system utilities.
Binaries compiled under 4.3BSD will work without  recompila-
tion  under 4.3BSD-Quasijarus, though they may run faster if
they are recompiled.  Binaries compiled  under  4.2BSD  will
probably  work  without recompilation, but it is a good idea
to recompile and relink  because  of  the  many  changes  in
header  files  and  libraries  since  4.2BSD.  4.1BSD binary
images can also run unchanged  under  4.3BSD-Quasijarus  but
only  when  the system is configured to include the ``4.1BSD
compatibility mode.''*

     The easiest upgrade path from 4.2BSD or 4.3BSD (depend-
ing  on your file system configuration) is to build new root
and /usr file systems on unused  partitions,  then  copy  or
merge  site specific files into their corresponding files on
the new system.  All user file systems can be retained unmo-
dified,  except  that the new fsck should be run before they
are mounted (see below).

     Section 3.1 lists the files to be saved as part of  the
conversion  process.   Section  3.2  describes the bootstrap
process.  Section 3.3 discusses  the  merger  of  the  saved
files  back  into the new system.  Section 3.4 provides gen-
eral hints on possible problems to be aware of when convert-
ing from 4.2BSD to 4.3BSD-Quasijarus.

3.1.  Files to save

     The following list enumerates the standard set of files

* With ``4.1BSD compatibility mode'' system calls  from
4.1BSD  are  either  emulated or safely ignored.  There
are only two exceptions: programs that read directories
or  use the old jobs library will not operate properly.
However,  while  4.1BSD  binaries  will  execute  under
4.3BSD-Quasijarus  it  is STRONGLY RECOMMENDED that the
programs be recompiled under the new system.




                      December 6, 2003





SMM:1-28ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


you will want to save  and  suggests  directories  in  which
site-specific  files  should  be  present.   This  list will
likely be augmented with non-standard files you  have  added
to  your  system.  If you do not have enough space to create
parallel file systems, you should create a tar image of  the
following files before the new file systems are created.  In
addition, it is STRONGLY advised that you  do  a  full  dump
before  rebuilding  the file system to guard against missing
something the first time around.
















































                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX29




        /.cshrc                +   root csh startup script
        /.login                +   root csh login script
        /.profile              +   root sh startup script
        /.rhosts               +   for trusted machines and users
        /dev/MAKEDEV           |   in case you added anything here
        /dev/MAKEDEV.local     *   for making local devices
        /etc/disktab           |   in case you changed disk partition sizes
        /etc/fstab             +   disk configuration data
        /etc/ftpusers          +   for local additions
        /etc/gateways          +   routing daemon database
        /etc/gettytab          |   getty database
        /etc/group             *   group data base
        /etc/hosts             +   for local host information
        /etc/hosts.equiv       +   for local host equivalence information
        /etc/networks          +   for local network information
        /etc/passwd            *   user data base
        /etc/printcap          +   line printer database
        /etc/protocols         |   in case you added any local protocols
        /etc/rc                *   for any local additions
        /etc/rc.local          *   site specific system startup commands
        /etc/remote            +   auto-dialer configuration
        /etc/services          |   for local additions
        /etc/syslog.conf       *   system logger configuration
        /etc/securettys        *   for restricted list of ttys where root can log in
        /etc/ttys              *   terminal line configuration data
        /etc/ttytype           *   terminal line to terminal type mapping data
        /etc/termcap           |   for any local entries that may have been added
        /lib                   |   for any locally developed language processors
        /usr/dict/*            |   for local additions to words and papers
        /usr/hosts/MAKEHOSTS   *   for local changes
        /usr/include/*         |   for local additions
        /usr/lib/aliases       |   mail forwarding data base
        /usr/lib/crontab       *   cron daemon data base
        /usr/lib/font/*        |   for locally developed font libraries
        /usr/lib/lib*.a        +   for locally libraries
        /usr/lib/lint/*        |   for locally developed lint libraries
        /usr/lib/sendmail.cf   *   sendmail configuration
        /usr/lib/tabset/*      |   for locally developed tab setting files
        /usr/lib/term/*        |   for locally developed nroff drive tables
        /usr/lib/tmac/*        |   for locally developed troff/nroff macros
        /usr/lib/uucp/*        +   for local uucp configuration files
        /usr/man/manl          *   for manual pages for locally developed programs
        /usr/msgs              +   for current msgs
        /usr/spool/*           +   for current mail, news, uucp files, etc.
        /usr/src/local         +   for source for locally developed programs
        /sys/conf/HOST         +   configuration file for your machine
        /sys/conf/files.HOST   +   list of special files in your kernel
        /*/quotas              +   file system quota files


        +Files that can be used from 4.2BSD or 4.3BSD without change.
        |Files that need local modifications merged into 4.3BSD-Quasijarus files.



                      December 6, 2003





SMM:1-30ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


        *Files that require special work to merge and are discussed
        in section 3.3.


3.2.  Installing 4.3BSD-Quasijarus

     The next step is to build a  working  4.3BSD-Quasijarus
system.   This can be done by following the steps in section
2 of this document for extracting the  root  and  /usr  file
systems  from  the distribution tape onto unused disk parti-
tions.  If you have a running 4.2BSD or 4.3BSD  system,  you
can  also  do  this by using dd(1) to copy the ``mini root''
filesystem onto one disk partition, then use it to load  the
4.3BSD-Quasijarus root filesystem as in chapter 2.  The root
filesystem  dump  on  the  tape  could  also  be   extracted
directly, although this will require an additional file sys-
tem check after booting 4.3BSD-Quasijarus to convert the new
root  filesystem.  The exact procedure chosen will depend on
the disk configuration and the number of suitable disk  par-
titions that may be used.  If there is insufficient space to
load the new root and /usr filesystems  before  reusing  the
existing  partitions,  it  is STRONGLY advised that you make
full dumps of each filesystem on magtape  before  beginning.
It  is  also  desirable  to  run  file  system checks of all
filesystems to  be  converted  to  4.3BSD-Quasijarus  before
shutting  down.   If  you  are  running  a system older than
4.2BSD, you will have to dump and restore your file systems;
see  section 2.1 for some hints.  In either case, this is an
excellent time to review your disk configuration for  possi-
ble  tuning  of  the  layout.  Section 4.2 and config(8) are
required reading.

     To ease the transition to new kernels, the  4.3BSD  and
4.3BSD-Quasijarus  bootstrap  routines  pass the identity of
the boot device through to the kernel.  The kernel then uses
that  device as its root file system.  Thus, for example, if
you boot from /dev/hp1a, the kernel will  use  hp1a  as  its
root file system.  If /dev/hp1b is configured as a swap par-
tition, it will be used as the initial swap area,  otherwise
the  normal primary swap area (/dev/hp0b) will be used.  The
4.3BSD-Quasijarus  bootstrap  is  backward  compatible  with
4.2BSD  and 4.3BSD, so you can replace your old bootstrap if
you use it to boot your first 4.3BSD-Quasijarus kernel.

     Once you have extracted  the  4.3BSD-Quasijarus  system
and  booted from it, you will have to build a kernel custom-
ized for your configuration.  If you have any  local  device
drivers, they will have to be incorporated into the new ker-
nel.  See section 4.2.3 and ``Building 4.3BSD  UNIX  Systems
with Config.''

     If converting from 4.2BSD,  4.3BSD,  or  the  CCI  1.21
release, your old file systems must be converted.  The stan-
dard disk partitions in 4.3BSD-Quasijarus are  the  same  as



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX31


those  in  4.2BSD  and  4.3BSD,  except for those on the DEC
UDA50; see section 4.3.2 for details.   If  you've  modified
the  partition  sizes from the original BSD or CCI ones, and
are not already using the 4.3BSD-Quasijarus disk labels, you
will  have  to modify the default disk partion tables in the
kernel.  Make the necessary table changes and boot your cus-
tom kernel BEFORE trying to access any of your old file sys-
tems!   After  doing  this,  if  necessary,  the   remaining
filesystems  may  be  converted  in  place  by  running  the
4.3BSD-Quasijarus version of fsck(8) on each filesystem  and
allowing it to make the necessary corrections.  The new ver-
sion of fsck is more strict about the  size  of  directories
than  the version supplied with 4.2BSD.  Thus the first time
that it is run on a 4.2BSD file system, it will produce mes-
sages of the form:

        DIRECTORY ...: LENGTH xx NOT MULTIPLE OF 512 (ADJUSTED)

Length ``xx'' will be the size of the directory; it will  be
expanded  to  the  next multiple of 512 bytes.  The new fsck
will also set default interleave and npsect (number of  phy-
sical  sectors  per  track) values on older file systems, in
which these fields were unused spares; this correction  will
produce messages of the form:

        IMPOSSIBLE INTERLEAVE=0 IN SUPERBLOCK (SET TO DEFAULT)*
        IMPOSSIBLE NPSECT=0 IN SUPERBLOCK (SET TO DEFAULT)

File systems that  have  had  their  interleave  and  npsect
values set will be diagnosed by the old fsck as having a bad
superblock; the old fsck will run only if given an alternate
superblock  (fsck -b32), in which case it will re-zero these
fields.  The 4.3BSD-Quasijarus kernel  will  internally  set
these  fields  to  their  defaults  if fsck has not done so;
again, the -b32 option may be necessary for running the  old
fsck.

     In addition, 4.3BSD-Quasijarus removes  several  limits
on  file  system  sizes that were present in both 4.2BSD and
4.3BSD.  The  limited  file  systems  continue  to  work  in
4.3BSD-Quasijarus,  but should be converted as soon as it is
convenient by running fsck with the -c option.  If  no  file
systems have been so converted, the sequence fsck -p -c will
update all of them, fix the interleave  and  npsect  fields,
and  fix  any  incorrect directory lengths all at once.  The
new unlimited file system formats are treated  as  read-only

* The defaults are to set interleave to 1 and npsect to
nsect;  this is correct on many drives.  Notable excep-
tions are the RM80 and RA81, where npsect should be set
to  one more than nsect.  This affects only performance
(and in the case of the RA81, at least,  virtually  un-
measurably).




                      December 6, 2003





SMM:1-32ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


by older systems.  A second fsck -c, however, will reconvert
the  new  format  to the old if none of the static limits of
the old file system format have been exceeded.  The new file
systems are otherwise compatible between 4.2BSD, 4.3BSD, and
4.3BSD-Quasijarus, though running a  4.3BSD-Quasijarus  file
system  under older systems may cause more of the above mes-
sages to be  generated  the  next  time  it  is  fsck'ed  on
4.3BSD-Quasijarus.

3.3.  Merging your files from 4.2  or  4.3BSD  into  4.3BSD-
Quasijarus

     When your system is booting reliably and you  have  the
4.3BSD-Quasijarus root and /usr file systems fully installed
you will be ready to continue with  the  next  step  in  the
conversion process, merging your old files into the new sys-
tem.

     If you saved the files on a tar tape, extract them into
a scratch directory, say /usr/convert:

        # mkdir /usr/convert
        # cd /usr/convert
        # tar xp


     The data files marked in  the  previous  table  with  a
dagger (+) may be used without change from the previous sys-
tem.  Those data files marked with a double dagger (|)  have
syntax  changes  or  substantial  enhancements.   You should
start  with  the  4.3BSD-Quasijarus  version  and  carefully
integrate  any  local  changes  into  the new file.  Usually
these local modifications can be incorporated  without  con-
flict  into  the  new file; some exceptions are noted below.
The files marked with an  asterisk  (*)  require  particular
attention and are discussed below.

     If  you  have   any   homegrown   device   drivers   in
/dev/MAKEDEV.local that use major device numbers reserved by
the system you will have to  modify  the  commands  used  to
create  the devices or alter the system device configuration
tables in /sys/vax/conf.c.  Otherwise /dev/MAKEDEV.local can
be used without change from 4.2 or 4.3BSD.

     System security  changes  require  adding  several  new
``well-known''  groups  to  /etc/group.  The groups that are
needed by the system as distributed are:










                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX33




        name       number
        

        wheel        0
        daemon       1
        kmem         2
        sys          3
        tty          4
        operator     5
        bin          10


Only users in the ``wheel'' group are  permitted  to  su  to
``root''.    Most   programs   that  manage  directories  in
/usr/spool now run set-group-id to ``daemon'' so that  users
cannot  directly  access the files in the spool directories.
The special files that access kernel memory,  /dev/kmem  and
/dev/mem,  are  made readable only by group ``kmem''.  Stan-
dard system programs that require this access are made  set-
group-id  to  that  group.  The group ``sys'' is intended to
control access to kernel sources, and other  sources  belong
to group ``bin.'' Rather than make user's terminals writable
by all users, they are now placed in group ``tty'' and  made
only group writable.  Programs that should legitimately have
access to write on user's terminals such as talkd and  write
now  run  set-group-id  to  ``tty''.  The ``operator'' group
controls access to disks.  By default, disks are readable by
group  ``operator'',  so that programs such as df can access
the file system information  without  being  set-user-id  to
``root''.   The  shutdown(8)  program  is executable only by
group operator and is setuid to  root  so  that  members  of
group operator may shut down the system without root access.

     Several new users have also been added to the group  of
``well-known'' users in /etc/passwd.  The current list is:


        name       number
        

        root         0
        daemon       1
        operator     2
        games        7
        uucp         66
        nobody     32767


The ``daemon'' user is used for daemon processes that do not
need  root  privileges.  The ``operator'' user-id is used as
an account for dumpers so that they can log in without  hav-
ing  the root password.  By placing them in the ``operator''
group, they can get read access to the disks.  The  ``uucp''
login  has  existed  long  before  4.3BSD-Quasijarus, and is



                      December 6, 2003





SMM:1-34ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


noted here just to provide a common user-id.   The  password
entry  ``nobody''  has  been  added to specify the user with
least privilege.  The ``games'' user is a  pseudo-user  that
controls access to game programs.

     After installing your updated password file,  you  must
run  mkpasswd(8) to create the ndbm password database.  Note
that mkpasswd is run whenever vipw(8) is run.

     The format of the  cron  table,  /usr/lib/crontab,  has
been  changed  to specify the user-id that should be used to
run a process.  The userid ``nobody'' is  frequently  useful
for non-privileged programs.

     Some of the commands previously in  /etc/rc.local  have
been moved to /etc/rc; several new functions are now handled
by /etc/rc, /etc/netstart  and  /etc/rc.local.   You  should
look  closely  at  the  prototype version of these files and
read the manual pages  for  the  commands  contained  in  it
before  trying to merge your local copy.  Note in particular
that ifconfig has had many changes, and that host names  are
now    fully   specified   as   domain-style   names   (e.g,
monet.Berkeley.EDU) for the benefit of the name server.

     The C library and system binaries on  the  distribution
tape  are  compiled  with  new versions of gethostbyname and
gethostbyaddr which use the name server, named(8).   If  you
have  only  a small network and are not connected to a large
network,  you  can  use  the  distributed  library  routines
without  any  problems;  they  use a linear scan of the host
table /etc/hosts if the name server is not running.  If  you
are  on the DARPA Internet or have a large local network, it
is recommend that you set up and use the name  server.   For
instructions  on  how  to set up the necessary configuration
files, refer to ``Name Server Operations Guide  for  BIND''.
Several  programs rely on the host name returned by gethost-
name to determine the local domain name.

     If you want to compile your  system  to  use  the  host
table  lookup  routines instead of the name server, you will
need to modify /usr/src/lib/libc/Makefile according  to  the
instructions  there and then recompile all of the system and
local programs  (see  section  6.6).   Next,  you  must  run
mkhosts(8)  to  create  the  ndbm  host  table database from
/etc/hosts.

     The format of /etc/ttys has changed,  see  ttys(5)  for
details.   It  now  includes  the terminal type and security
options that were  previously  placed  in  /etc/ttytype  and
/etc/securettys.

     There is a new version of syslog that uses a more  gen-
eralized  facility/priority  scheme.   This  has changed the
format of the syslog.conf file.  See syslogd(8) for details.



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX35


Syslog  now logs kernel errors, allowing events such as soft
disk errors, filesystem-full messages, and other such  error
messages  to be logged without slowing down the system while
the messages print on the console.  It is also used by  many
of  the  system  daemons  to  monitor  system  problems more
closely, for example network routing changes.

     If you are using the name server, your sendmail  confi-
guration  file  will  need some minor updates to accommodate
it.  See the ``Sendmail Installation and  Operation  Guide''
and    the    sample   sendmail   configuration   files   in
/usr/src/usr.lib/sendmail/cf.   The  sendmail.cf's  supplied
with  this  release  are alleged to be ``generic'', but have
only really seen use at Berkeley.  In particular  there  are
two  points  to watch out for.  First, all host names in the
sendmail.cf itself must be fully qualified  names.   Second,
the  sendmail.cf's  assume you have a /usr/lib/sendmail that
was compiled with the resolver  library  (i.e.,  not  hostt-
ables).  This is necessary to canonicalize unqualified names
into  fully-qualified  names  (e.g.,  foo  ->  foo.bar.com).
Using  these  .cf  files  with  a host table can probably be
done, but it will be difficult.  Be sure to regenerate  your
sendmail  frozen  configuration  file  after installation of
your   updated   configuration   file   with   the   command
/usr/lib/sendmail  -bz.   The aliases file, /usr/lib/aliases
has also been changed to add certain well-known addresses.

     The spooling directories saved on tape may be  restored
in  their  eventual resting places without too much concern.
Be sure to use the `p' option  to  tar  so  that  files  are
recreated with the same file modes:

        # cd /usr
        # tar xp msgs spool/mail spool/uucp spool/uucppublic spool/news


     The following two  sections  contain  additional  notes
concerning  changes  in  4.3BSD-Quasijarus  that  affect the
installation of local files; be sure to read them as well.

3.4.  Hints on converting from 4.2BSD to 4.3BSD-Quasijarus

     This section summarizes the  most  significant  changes
between  4.2BSD  and  4.3BSD,  particularly  those  that are
likely to cause difficulty in doing the conversion.  It does
not include changes in the network; see chapter 5 for infor-
mation on setting up the network.

     The mailbox locking protocol has changed; it  now  uses
the  advisory locking facility to avoid concurrent update of
users' mail boxes.  If you have your own mail interface,  be
sure to update its locking protocol.

     The kernel's limit on the number of open files has been



                      December 6, 2003





SMM:1-36ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


increased  from 20 to 64.  It is now possible to change this
limit almost arbitrarily (there used to be a hard  limit  of
30).   The standard I/O library autoconfigures to the kernel
limit.  Note that file (`` iob'') entries may  be  allocated
by  malloc  from  fopen;  this  allocation has been known to
cause problems with programs that use their own memory allo-
cators.   This does not occur until after 20 files have been
opened by the standard I/O library.

     Select can be used with more  than  32  descriptors  by
using  arrays  of ints for the bit fields rather than single
ints.  Programs that used getdtablesize as their first argu-
ment  to  select will no longer work correctly.  Usually the
program can be modified to correctly specify the  number  of
bits  in  an int.  Alternatively the program can be modified
to use an array of ints.  There are a set of  macros  avail-
able in <sys/types.h> to simplify this.  See select(2).

     Old core files will not be intelligible by the  current
debuggers  because of numerous changes to the user structure
and because the kernel stack has been enlarged.   The  a.out
header  that was in the user structure is no longer present.
Locally-written debuggers that try to check the magic number
will need modification.

     Find now has a database of file names, constructed once
a  week from cron.  To find a file by name only, the command
find name will look in the database for files that match the
name.  This is much faster than find / -name name -print.

     Files may not be deleted from  directories  having  the
``sticky''  (ISVTX)  bit  set  in  their modes except by the
owner of the file or of the directory, or by the  superuser.
This  is  primarily  to  protect  users'  files in publicly-
writable  directories  such  as  /tmp  and  /usr/tmp.    All
publicly-writable  directories  should have their ``sticky''
bits set with ``chmod +t.''

     The include file <time.h> has returned to /usr/include,
and  again  contains  the definitions for the C library time
routines of ctime(3).

     The compact and uncompact programs have been supplanted
by  the  faster  compress.  If your user population has com-
pacted files,  you  will  want  to  install  uncompact  from
/usr/src/old/compact.

     The configuration of the virtual memory limits has been
simplified.   A  MAXDSIZ  option,  specified in bytes in the
machine configuration file, may be used to raise the maximum
process  region  size  from  the  default of 17Mb to 32Mb or
64Mb.  The initial per-process limit is still 6Mb,  but  can
be raised up to MAXDSIZ with the csh limit command.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX37


     Some 4.3BSD-Quasijarus binaries will  not  run  with  a
4.2BSD kernel because they take advantage of new functional-
ity in 4.3BSD-Quasijarus.  One noticeable  example  of  this
problem is csh.

     If you want to use ps after booting a new  kernel,  and
before  going  multiuser,  you must initialize its name list
database by running ps -U.

3.5.  Hints on converting from 4.3BSD to 4.3BSD-Quasijarus

     The largest visible change between  4.3BSD  to  4.3BSD-
Quasijarus  (other than the addition of support for new pro-
cessors) is the addition of support for disk  labels.   This
facility  allows  each  disk  or  disk  pack  to contain all
geometry information about the disk and the partition layout
for  the  disk.  Disk labels are supported on all disk types
on the Tahoe machines, and on hp and ra/rd disks on the VAX.
See  section 2.1.6 as well as disklabel(8) and disklabel(5).
Installation of this facility requires use of the new kernel
and  device  drivers,  bootstraps  and other standalone pro-
grams,  /etc/disktab,  bad144(8V),  newfs(8),  and  probably
other programs.

     The bootstrap programs  have  been  fixed  to  work  on
MicroVAX  IIs  and VAXstation II's with QVSS (VS II) or QDSS
(GPX)  displays;  the  kernel  includes  support  for  these
displays,  courtesy  of Digital Equipment Corp.  In order to
install the bootstrap on RD52/53/54 disks with disklabel(8),
the  new /etc/disktab must be used, or the block 0 bootstrap
must be explictly listed as /usr/mdec/rdboot (not raboot).

     The order in which daemons are started by  /etc/rc  and
/etc/rc.local  has  changed,  and network initialization has
been split into /etc/netstart.  Look at the prototype files,
and modify /etc/rc.local as necessary; c.f. section 5.6.1.

     4.3BSD-Quasijarus includes the Olson timezone implemen-
tation,  which uses timezone and daylight-savings-time rules
loaded  from  files  in  /etc/zoneinfo;  see  ctime(3)   and
tzfile(5).

     The type of the sprintf(3S) function has  been  changed
from  char  * in 4.2BSD and 4.3BSD to int as in the proposed
ANSI C standard and in System V.  Programers are discouraged
from  using  the return value from sprintf until this change
is ubiquitous.  Fortunately, the previous return value  from
sprintf was essentially useless.

     The  ownership  and  modes  of  some  directories  have
changed.   The  at  programs  now  run  set-user-id ``root''
instead of ``daemon.'' Also, the uucp  directory  no  longer
needs  to be publicly writable, as tip reverts to privileged
status to remove its lock files.  After copying your version



                      December 6, 2003





SMM:1-38ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


of /usr/spool, you should do:

        # chown -R root /usr/spool/at
        # chown -R uucp.daemon /usr/spool/uucp
        # chmod -R o-w /usr/spool/uucp


     The MAKEHOSTS file has moved from /usr/hosts to /usr.

     The source versions of the manual pages have been moved
from  /usr/man/man[1-8]  to  /usr/src/man, /usr/src/new/man,
and /usr/src/local/man.  Local manual pages should be  moved
into  their  respective  source  code  directories,  or into
/usr/src/local/man/man[1-8],  and   Makefiles   changed   to
install      the     formatted     manual     pages     into
/usr/local/man/cat[1-8].  The shell script  /usr/man/manroff
calls  nroff with the standard manual arguments.  An example
of installing a manual page might be:

        # /usr/man/manroff example.2 > example.0
        # install -o bin -g bin -m 444 example.0 /usr/local/man/cat2


     Whatever else is left is likely to be site specific  or
require  careful  scrutiny  before  placing  in its eventual
resting place.  Refer to the documentation and  source  code
before arbitrarily overwriting a file.






























                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX39


                      4. SYSTEM SETUP



     This section describes procedures used to set up a  VAX
UNIX  system.   These  procedures  are used when a system is
first installed or when the  system  configuration  changes.
Procedures  for normal system operation are described in the
next section.

4.1.  Creating UNIX boot media

     The procedures for making the various UNIX  boot  media
are  described  in this section.  If you have an 11/780, you
will need to make a floppy.  Making a console floppy is also
recommended  for  8200.   For  an  11/730 (and rarely for an
11/750), you will need to make a cassette.  For an 8600, you
will need to make a console RL02 pack.

     The boot command files are all set up for  booting  off
of the first UNIBUS or MASSBUS.  If you are booting off of a
different UNIBUS or MASSBUS, you will  need  to  modify  the
boot command files appropriately.

4.1.1.  Making a UNIX boot console RL02 pack

     If you have an 8600 you will want to create a UNIX boot
console  RL02  pack by adding some files to your current DEC
console pack, using arff(8).  If you do not want  to  modify
your  current  DEC  console  pack, you may make a copy of it
first using dd(1).  This pack will  make  standalone  system
operations such as bootstrapping much easier.

     First change into the directory where the console  RL02
information is stored:

        # cd /sys/consolerl

then set up the default boot device.  If you have an RK07 as
your primary root do:

        # cp defboo.hk defboo.com

If you have a drive on a UDA50 (e.g. an RA81) as  your  pri-
mary root do:

        # cp defboo.ra defboo.com

If you have a second vendor UNIBUS storage  module  as  your
primary root do:

        # cp defboo.up defboo.com

Otherwise:



                      December 6, 2003





SMM:1-40ling and Operating 4.3BSD-Quasijarus UNIX on the VAX



        # cp defboo.hp defboo.com

The final step in updating the console RL02 pack is:

        # make update

More copies of this console RL02  pack  can  be  made  using
dd(1).

4.1.2.  Making a UNIX boot floppy

     If you have an 11/780 you will want to  create  a  UNIX
boot  floppy  by adding some files to a copy of your current
DEC console floppy, using either  flcopy(8)  or  dd(1),  and
using  arff(8).   This  floppy  will  make standalone system
operations such as bootstrapping much easier.

     First change  into  the  directory  where  the  console
floppy information is stored:

        # cd /sys/floppy

then set up the default boot device.  If you have an RK07 as
your primary root do:

        # cp defboo.hk defboo.cmd

If you have a drive on a UDA50 (e.g. an RA81) as  your  pri-
mary root do:

        # cp defboo.ra defboo.cmd

If you have a second vendor UNIBUS storage  module  as  your
primary root do:

        # cp defboo.up defboo.cmd

Otherwise:

        # cp defboo.hp defboo.cmd

On an  11/780,  if  the  local  configuration  requires  any
changes  in  restar.cmd or defboo.cmd (e.g., for interleaved
old-style memory controllers see defboo.MS780C-interleaved),
these  should  be made now.  The following command will then
copy your  DEC  local  console  floppy,  updating  the  copy
appropriately.

        # make update
        Change Floppy, Hit return when done.
        (waits for you to put clean floppy in console)
        Are you sure you want to clobber the floppy? yes




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX41


More copies of this floppy can be made using flcopy(8).

     On an 8200 it is recommended to  make  a  UNIX  console
RX50  floppy, although it is not required if you use the ROM
to boot directly from a KDB50 or UDA50.  Since the 8200 does
not  need  any  CPU microcode or front end processor code on
the console floppy, the distribution  console  RX50  may  be
used for booting and as a maintenance aid.  There is no need
to make  a  different  console  floppy.   If  you  have  not
received  a console RX50 with your 4.3BSD-Quasijarus distri-
bution, you can make one with the following commands:

        # cd /sys/rx50
        # make
        # make install

The defboo.cmd and sngboo.cmd command scripts are set up for
booting  from  the  first KDB50.  If you need to boot from a
KDB50 other than the first, or from  an  UDA50,  change  the
scripts accordingly prior to running make.

4.1.3.  Making a UNIX boot cassette

     If you have an 11/730 you will want to  create  a  UNIX
boot cassette by adding some files to a copy of your current
DEC console cassette, using  flcopy(8)  and  arff(8).   This
cassette  will  make  standalone  system  operations such as
bootstrapping much easier.

     First change  into  the  directory  where  the  console
cassette information is stored:

        # cd /sys/cassette

then set up the default boot device.  If  you  have  an  IDC
storage module as your primary root do:

        # cp defboo.rb defboo.cmd

If you have an RK07 as your primary root do:

        # cp defboo.hk defboo.cmd

If you have a drive on a UDA50 as your primary root do:

        # cp defboo.ra defboo.cmd

Otherwise:

        # cp defboo.up defboo.cmd

To complete the  procedure  place  your  DEC  local  console
cassette  in  drive  0  (the drive at front of the CPU); the
following command will  then  copy  it,  updating  the  copy



                      December 6, 2003





SMM:1-42ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


appropriately.

        # make update
        Change Floppy, Hit return when done.
        (waits for you to put clean cassette in console drive 0)
        Are you sure you want to clobber the floppy? yes

More copies of this cassette can best be made using dd(1).

     Although it is rarely necessary, you can also create  a
console cassette for a 750 with BOOT58.  You will need to do
this if you cannot obtain a boot PROM for your system  disk.
Contact  Quasijarus Consortium for assistance if you need to
do this.

4.2.  Kernel configuration

     This section briefly describes the layout of the kernel
code and how files for devices are made.  For a full discus-
sion of configuring and building system images, consult  the
document ``Building 4.3BSD UNIX Systems with Config''.

4.2.1.  Kernel organization

     As distributed, the kernel source is in a separate  tar
image.  The source may be physically located anywhere within
any file system so long as a symbolic link to  the  location
is created for the file /sys (many files in /usr/include are
normally symbolic links relative to /sys).  In further  dis-
cussions  of  the system source all path names will be given
relative to /sys.

     The directory /sys/sys contains  the  mainline  machine
independent operating system code.  Files within this direc-
tory are conventionally named with the following prefixes:


        init         system initialization
        kern         kernel (authentication, process management, etc.)
        quota        disk quotas
        sys          system calls and similar
        tty          terminal handling
        ufs          file system
        uipc         interprocess communication
        vm           virtual memory



     The remaining directories are organized as follows:








                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX43




        /sys/h            machine-independent include files
        /sys/conf         site configuration files and basic templates
        /sys/kdb          machine-independent part of the kernel debugger
        /sys/net          protocol-independent, but network-related code
        /sys/netimp       IMP support code
        /sys/netinet      DARPA Internet code
        /sys/netns        Xerox NS code
        /sys/stand        machine-independent standalone code
        /sys/tahoe        Tahoe-specific mainline code
        /sys/tahoealign   Tahoe unaligned-reference emulation code
        /sys/tahoedist    Tahoe distribution files
        /sys/tahoeif      Tahoe network interface code
        /sys/tahoevba     Tahoe VERSAbus device drivers and related code
        /sys/tahoemath    Tahoe floating point emulation code
        /sys/tahoestand   Tahoe standalone device drivers and related code
        /sys/vax          VAX-specific mainline code
        /sys/vaxbi        VAX BI device drivers and related code
        /sys/vaxdist      VAX distribution files
        /sys/vaxif        VAX network interface code
        /sys/vaxmba       VAX MASSBUS device drivers and related code
        /sys/vaxstand     VAX standalone device drivers and boot code
        /sys/vaxuba       VAX UNIBUS device drivers and related code



     Many  of  these  directories  are  referenced   through
/usr/include    with    symbolic    links.    For   example,
/usr/include/sys is a symbolic link to /sys/h.   The  system
code,  as distributed, is totally independent of the include
files in /usr/include.  This allows the system to be  recom-
piled from scratch without the /usr file system mounted.

4.2.2.  Devices and device drivers

     Devices supported by UNIX are implemented in the kernel
by  drivers  whose  source  is kept in /sys/vax, /sys/vaxbi,
/sys/vaxuba, or /sys/vaxmba.  These drivers are loaded  into
the  system  when  included  in a cpu specific configuration
file kept in  the  conf  directory.   Devices  are  accessed
through  special  files  in  the  file  system,  made by the
mknod(8) program and normally kept in  the  /dev  directory.
For  all  the  devices supported by the distribution system,
the files in /dev are  created  by  the  /dev/MAKEDEV  shell
script.

     Determine the set of devices that you have and create a
new  /dev  directory  by  running the MAKEDEV script.  First
create a new directory /newdev, copy MAKEDEV into  it,  edit
the  file MAKEDEV.local to provide an entry for local needs,
and run it to generate a /newdev directory.   For  instance,
if  your  machine has a single DZ11, a single DH11, a single
DMF32, an RM03 disk, an EMULEX UNIBUS SMD  disk  controller,



                      December 6, 2003





SMM:1-44ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


an AMPEX 9300 disk, and a TE16 tape drive you would do:

        # cd /
        # mkdir newdev
        # cp dev/MAKEDEV newdev/MAKEDEV
        # cd newdev
        # MAKEDEV dz0 dh0 dmf0 hp0 up0 ht0 std LOCAL

Note the ``std'' argument causes standard  devices  such  as
/dev/console,  the machine console, /dev/floppy, the console
floppy  disk  interface  for  the  11/780  and  11/785,  and
/dev/tu0  and  /dev/tu1, the console cassette interfaces for
the 11/750 and 11/730, to be created.

     You can then do

        # cd /
        # mv dev olddev ; mv newdev dev
        # sync

to install the new device directory.

4.2.3.  Building new system images

     The  kernel  configuration  of  each  UNIX  system   is
described  by  a  single  configuration  file, stored in the
/sys/conf directory.  To learn about the format of this file
and  the  procedure  used  to  build system images, start by
reading ``Building 4.3BSD UNIX Systems with  Config'',  look
at  the manual pages in section 4 of the UNIX manual for the
devices you have, and look at the sample configuration files
in the /sys/conf directory.

     The configured system image ``vmunix'' should be copied
to  the  root, and then booted to try it out.  It is best to
name it /newvmunix so as not to destroy the  working  system
until you're sure it does work:

        # cp vmunix /newvmunix
        # sync

It is also a good idea to keep the  previous  system  around
under some other name.  In particular, we recommend that you
save the generic distribution version  of  the  system  per-
manently  as /genvmunix for use in emergencies.  To boot the
new version of the system you should  follow  the  bootstrap
procedures outlined in section 6.1.  After having booted and
tested the new system, it should  be  installed  as  /vmunix
before  going into multiuser operation.  A systematic scheme
for numbering and saving old versions of the system  may  be
useful.






                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX45


4.3.  Disk configuration

     This section describes how to layout  file  systems  to
make use of the available space and to balance disk load for
better system performance.

4.3.1.  Initializing /etc/fstab

     Change into the directory /etc and copy the appropriate
file from:

        fstab.rm03
        fstab.rm05
        fstab.rm80
        fstab.ra60
        fstab.ra80
        fstab.ra81
        fstab.rb80
        fstab.rp06
        fstab.rp07
        fstab.rk07
        fstab.up160m (160MB up drives)
        fstab.hp400m (400MB hp drives)
        fstab.up (other up drives)
        fstab.hp (other hp drives)

to the file /etc/fstab, i.e.:

        # cd /etc
        # cp fstab.xxx fstab


     This will set up  the  default  information  about  the
usage  of  disk  partitions, which we see how to update more
below.

4.3.2.  Disk naming and divisions

     Each physical disk drive can be divided into  up  to  8
partitions; UNIX typically uses only 3 or 4 partitions.  For
instance, on an RM80, the first partition, hp0a, is used for
a root file system, a backup thereof, or a small file system
like, /tmp; the second partition, hp0b, is used  for  paging
and  swapping;  and  the third partition, hp0g, holds a user
file system.  On an RM05, the  first  three  partitions  are
used  as for the RM80, and the fourth partition, hp0h, holds
the /usr file system, including source code.

     The disk partition sizes for a drive are based on a set
of  four  prototype  partition tables; c.f. diskpart(8). The
particular table used is dependent on the size of the drive.
The  ``a''  partition  is  the  same size across all drives,
15884 sectors.  The ``b'' partition,  used  for  paging  and
swapping, is sized according to the total space on the disk.



                      December 6, 2003





SMM:1-46ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


For drives less than about 400 megabytes  the  partition  is
33440 sectors, while for larger drives the partition size is
doubled to 66880 sectors.  The  ``c''  partition  is  always
used to access the entire physical disk, including the space
at the back of the disk reserved for the bad sector forward-
ing  table.  If the disk is larger than about 250 megabytes,
an ``h'' partition is created with size 291346 sectors,  and
no matter whether the ``h'' partition is created or not, the
remainder of the drive is allocated to the ``g''  partition.
Sites that want to split up the ``g'' partition into several
smaller file systems may use the  ``d'',  ``e'',  and  ``f''
partitions  that  overlap  the ``g'' partition.  The default
sizes  for  these  partitions  are  15884,  55936,  and  the
remainder of the disk, respectively*.

     The disk partition sizes for DEC RA60, RA80,  and  RA81
have  changed  since  4.2BSD.  If upgrading from 4.2BSD, you
will need to decide if you want to use the new partitions or
the  old  partitions.   If  you desire to use the old parti-
tions, you will need to label your packs as  `racompat',  or
create  your own by updating /etc/disktab.  Any other parti-
tion sizes that were modified at your site will require  the
same  consideration;  if  the device driver does not support
pack labels, you will have to update its compiled-in  tables
as well.

     The space available on a disk varies per  device.   The
amount  of  space available on the common disk partitions is
listed in the following table.  Not shown in the  table  are
the partitions of each drive devoted to the root file system
and the paging area.  Many other partitions  are  listed  in
the  standard  partitions,  but most of them are not useful.
Note that the standard partition tables usually list several
alternative ways to divide a disk, but that only nonoverlap-
ping partitions may be used on any one disk.














* These rules are, unfortunately, not evenly applied to
all  disks.  /etc/disktab, and the pack label or driver
tables, give the final word; consult section 4  of  the
manual, and read /etc/disktab, for more information.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX47




               Type    Name    Size    Name    Size
               

               rk07    hk?g    13 Mb
               rm03    hp?g    41 Mb
               rp06    hp?g   145 Mb
               rm05    hp?g    80 Mb   hp?h   145 Mb
               rm80    hp?g    96 Mb
               ra60    ra?g    78 Mb   ra?h    96 Mb
               ra80    ra?g    96 Mb
               ra81    ra?g   257 Mb   ra?h   145 Mb
               rb80    rb?g    41 Mb   rb?h    56 Mb
               rp07    hp?g   315 Mb   hp?h   145 Mb
               up300   up?g    80 Mb   up?h   145 Mb
               up330   up?g    90 Mb   up?h   145 Mb
               up400   hp?g   216 Mb   hp?h   145 Mb
               up160   up?g   106 Mb



Here up300 refers to either an AMPEX  or  CDC  300  megabyte
disk on a MASSBUS or UNIBUS disk controller, up330 refers to
either an AMPEX or FUJITSU 330 megabyte disk on a MASSBUS or
UNIBUS  controller,  up160  refers to a FUJITSU 160 megabyte
disk on the UNIBUS, and up400 refers to a FUJITSU Eagle  400
megabyte disk on a MASBUS or UNIBUS disk controller.  ``hp''
should be substituted for ``up'' above if the disk is on the
MASSBUS.   Consult  the  manual  pages for the specific con-
trollers for other supported disks or other partitions.

     Each disk also has a paging area,  typically  16  mega-
bytes, and a root file system of 7.5 megabytes.  The distri-
buted system binaries occupy about 34  megabytes  while  the
major  sources  occupy another 32 megabytes.  This overflows
dual RK07, dual RL02  and  single  RM03  systems,  but  fits
easily on most other hardware configurations.

     Be aware that the disks have their  sizes  measured  in
disk sectors (usually 512 bytes), while the UNIX file system
blocks are variable sized.  All user  programs  report  disk
space  in kilobytes and, where needed, disk sizes are always
specified in units of sectors.  The /etc/disktab  file  used
in  labelling  disks  and making file systems specifies disk
partition  sizes  in  sectors;  the  default   sector   size
(DEV BSIZE  as  defined in /sys/h/param.h) may be overridden
with the ``se'' attribute.

4.3.3.  Layout considerations

     There are several considerations  in  deciding  how  to
adjust  the  arrangement  of things on your disks.  The most
important is making sure that there is  adequate  space  for
what   is   required;   secondarily,  throughput  should  be



                      December 6, 2003





SMM:1-48ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


maximized.  Paging space is  an  important  parameter.   The
system,  as  distributed,  sizes the configured paging areas
each time the system is booted.   Further,  multiple  paging
areas  of different size may be interleaved.  Drives smaller
than 400 megabytes have  swap  partitions  of  16  megabytes
while  drives  larger  than 400 megabytes have 32 megabytes.
These values may be changed to  get  more  paging  space  by
changing  the  label  (or,  if  labels  are unsupported, the
appropriate partition table in the disk driver).

     Many common system programs (C, the editor, the  assem-
bler  etc.) create intermediate files in the /tmp directory,
so the file system where this is stored also should be  made
large  enough  to  accommodate most high-water marks; if you
have several disks, it  makes  sense  to  mount  this  in  a
``root'' (i.e. first partition) file system on another disk.
All the programs that create files  in  /tmp  take  care  to
delete them, but are not immune to rare events and can leave
dregs.  The directory should be examined every so often  and
the old files deleted.

     The efficiency with which UNIX is able to use  the  CPU
is often strongly affected by the configuration of disk con-
trollers.  For general time-sharing applications,  the  best
strategy is to try to split the root file system (/), system
binaries (/usr), the temporary files (/tmp),  and  the  user
files  among several disk arms, and to interleave the paging
activity among several arms.

     It is critical for good  performance  to  balance  disk
load.   There  are at least five components of the disk load
that you can divide between the available disks:

        1. The root file system.
        2. The /tmp file system.
        3. The /usr file system.
        4. The user files.
        5. The paging activity.

The following possibilities are ones we have used  at  times
when we had 2, 3 and 4 disks:

             

                                disks
              what      2       3       4
             

              /         0       0       0
              tmp       1       2       3
              usr       1       1       1
              paging    0+1     0+2     0+2+3
              users     0       0+2     0+2
              archive   x       x       3
             

            |
            |
            |
            |
            |

            |
            |
            |
            |








            |
            |
            |
            |
            |
            |
            |
            |
            |
            |









                     |
                     |
                     |
                     |
                     |
                     |
                     |
                     |
                     |








                             |
                             |
                             |
                             |
                             |
                             |
                             |
                             |
                             |







                                     |
                                     |
                                     |
                                     |
                                     |
                                     |
                                     |
                                     |
                                     |







                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |








                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |














                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX49


     The most important things to consider are to  even  out
the  disk load as much as possible, and to do this by decou-
pling file systems (on separate arms)  between  which  heavy
copying occurs.  Note that a long term average balanced load
is not important; it is  much  more  important  to  have  an
instantaneously balanced load when the system is busy.

     Intelligent experimentation  with  a  few  file  system
arrangements  can  pay off in much improved performance.  It
is particularly easy to move the root, the /tmp file  system
and  the  paging  areas.   Place the user files and the /usr
directory as space needs dictate  and  experiment  with  the
other, more easily moved file systems.

4.3.4.  File system parameters

     Each file system  is  parameterized  according  to  its
block  size,  fragment  size,  and the disk geometry charac-
teristics of the medium on  which  it  resides.   Inaccurate
specification  of  the  disk  characteristics  or  haphazard
choice of the file system parameters can result in  substan-
tial  throughput  degradation  or  significant waste of disk
space.  As distributed, file systems are configured  accord-
ing to the following table.


              File system   Block size   Fragment size
              

              /             8 kbytes     1 kbytes
              usr           4 kbytes     1 kbytes
              users         4 kbytes     1 kbytes



     The root file system block size is made large to optim-
ize  bandwidth to the associated disk;  this is particularly
important since the /tmp directory is normally part  of  the
root  file or a similar filesystem.  The large block size is
also important as many of the most heavily used programs are
demand  paged  out of the /bin directory.  The fragment size
of 1 kbyte is a ``nominal'' value to use with a file system.
With a 1 kbyte fragment size disk space utilization is about
the same as with the earlier versions of the file system.

     The usr file system would like to use a 4  kbyte  block
size  with  512  byte fragment size in an effort to get high
performance while conserving the amount of space wasted by a
large  fragment  size.   However, the tahoe disk controllers
require a minimum block size of 1 Kbyte.   Space  compaction
has  been  deemed important here because the source code for
the system is normally placed on this file system.   If  the
source  code is placed on a separate filesystem, use of an 8
kbyte block size with 1 kbyte fragments might be  considered
for improved performance when paging from /usr binaries.



                      December 6, 2003





SMM:1-50ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


     The file systems for users have a 4  kbyte  block  size
with  1  kbyte  fragment  size.   These parameters have been
selected based on observations of  the  performance  of  our
user file systems.  The 4 kbyte block size provides adequate
bandwidth while the 1 kbyte fragment size  provides  accept-
able space compaction and disk fragmentation.

     Other parameters may be  chosen  in  constructing  file
systems,  but  the factors involved in choosing a block size
and fragment size are many and  interact  in  complex  ways.
Larger  block  sizes  result  in  better throughput to large
files in the file system as larger I/O requests will then be
performed  by  the  system.   However, consideration must be
given to the average file sizes found in the file system and
the  performance  of the internal system buffer cache.   The
system currently provides space in the inode for  12  direct
block  pointers, 1 single indirect block pointer, and 1 dou-
ble indirect block pointer.* If  a  file  uses  only  direct
blocks,  access  time  to it will be optimized by maximizing
the block size.  If a file  spills  over  into  an  indirect
block,  increasing  the  block  size  of the file system may
decrease the amount of space used by eliminating the need to
allocate  an  indirect block.  However, if the block size is
increased and an indirect block is still required, then more
disk  space will be used by the file because indirect blocks
are allocated according to the block size of the  file  sys-
tem.

     In selecting a fragment size  for  a  file  system,  at
least two considerations should be given.  The major perfor-
mance tradeoffs observed are between an 8 kbyte  block  file
system  and  a 4 kbyte block file system.  Because of imple-
mentation constraints, the block size / fragment size  ratio
can  not be greater than 8.  This means that an 8 kbyte file
system will always have  a  fragment  size  of  at  least  1
kbytes.   If  a  file system is created with a 4 kbyte block
size and a 1 kbyte fragment size,  then  upgraded  to  an  8
kbyte  block size and 1 kbyte fragment size, identical space
compaction will be observed.  However, if a file system  has
a  4 kbyte block size and 512 byte fragment size, converting
it to an 8K/1K file system will result in significantly more
space being used.  This implies that 4 kbyte block file sys-
tems that might be upgraded to 8  kbyte  blocks  for  higher
performance  should  use fragment sizes of at least 1 kbytes
to minimize the amount of work required in conversion.

     A second, more important, consideration when  selecting
the fragment size for a file system is the level of fragmen-
tation on the disk.  With an 8:1 fragment  to  block  ratio,
storage  fragmentation occurs much sooner, particularly with

* A triple indirect block pointer is also reserved, but
not currently supported.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX51


a busy file system running  near  full  capacity.   By  com-
parison,  the  level  of  fragmentation in a 4:1 fragment to
block ratio file system is one tenth as severe.  This  means
that  on  file  systems  where  many  files  are created and
deleted, the 512 byte fragment size is more likely to result
in apparent space exhaustion because of fragmentation.  That
is, when the file system is nearly full, file expansion that
requires  locating  a  contiguous area of disk space is more
likely to fail on a 512 byte file system than on a  1  kbyte
file  system.   To  minimize  fragmentation problems of this
sort, a parameter in the super  block  specifies  a  minimum
acceptable  free  space  threshold.  When normal users (i.e.
anyone but the super-user) attempt to  allocate  disk  space
and  the  free  space  threshold  is  exceeded,  the user is
returned an error as if the file system  were  really  full.
This parameter is nominally set to 10%; it may be changed by
supplying a parameter to newfs(8), or by updating the  super
block of an existing file system using tunefs(8).

     In general, unless a file system is to be  used  for  a
special purpose application (for example, storing image pro-
cessing data), we recommend using the values supplied above.
Remember  that  the  current implementation limits the block
size to at most 8 kbytes and the ratio of block size / frag-
ment size must be 1, 2, 4, or 8.

     The disk geometry information used by the  file  system
affects  the  block  layout  policies  employed.   The  file
/etc/disktab, as supplied, contains the data  for  most  all
drives  supported by the system.  Before constructing a file
system with newfs(8) you should label the disk  (if  it  has
not  yet  been labeled, and the driver supports labels).  If
labels cannot be used, you must instead specify the type  of
disk  on  which  the  file  system resides; newfs then reads
/etc/disktab instead of the pack label.  This file also con-
tains  the  default file system partition sizes, and default
block and fragment sizes.  To override any  of  the  default
values  you can modify the file, edit the disk label, or use
an option to newfs.

4.3.5.  Implementing a layout

     To put a chosen disk layout into effect, you should use
the  newfs(8)  command to create each new file system.  Each
file system must also be added to  the  file  /etc/fstab  so
that  it  will  be  checked  and  mounted when the system is
bootstrapped.

     As an example, consider a system with RM80's.   On  the
first  RM80,  hp0, we will put the root file system in hp0a,
and the /usr file system in hp0, which has enough  space  to
hold  it  and then some.  The /tmp directory will be part of
the root file system, as no file system will be  mounted  on
/tmp.   If  we had only one RM80, we would put user files in



                      December 6, 2003





SMM:1-52ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


the hp0 partition with the system source and binaries.

     If we had a second RM80, we would place /usr  in  hp1g.
We would put user files in hp0g, calling the file system /a.
We would also interleave the paging between  the  2  RM80's.
To do this we would build a system configuration that speci-
fied:

        config  vmunix  root on hp0 swap on hp0 and hp1

to get the swap interleaved, and /etc/fstab would then  con-
tain

        /dev/hp0a:/:rw:1:1
        /dev/hp0b::sw::
        /dev/hp0g:/a:rw:1:2
        /dev/hp1b::sw::
        /dev/hp1g:/usr:rw:1:2

We would keep a backup copy of the root file system  in  the
hp1a disk partition.  Alternatively, that partition could be
used for /tmp.

     To make the /a file system we would do:

        # cd /dev
        # MAKEDEV hp1
        # disklabel -wr hp1 RM80 "disk name"
        # newfs hp1g
        (information about file system prints out)
        # mkdir /a
        # mount /dev/hp1g /a


4.4.  Configuring terminals

     If  UNIX  is  to  support  simultaneous   access   from
directly-connected  terminals  other  than  the console, the
file /etc/ttys (ttys(5)) must be edited.

     Terminals connected via DZ11 interfaces are convention-
ally  named  ttyDD where DD is a decimal number, the ``minor
device'' number.  The lines on  dz0  are  named  /dev/tty00,
/dev/tty01, ... /dev/tty07.  By convention, all other termi-
nal names are of the form ttyCX, where C  is  an  alphabetic
character  according to the type of terminal multiplexor and
its unit number, and X is a digit for the first ten lines on
the  interface  and  an increasing lower case letter for the
rest of the lines.  C is defined for the  number  of  inter-
faces of each type listed below.







                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX53




      

       Interface                Number of lines   Number of
         Type      Characters      per board      Interfaces
      

       DZ11        see above           8              10
       DMF32        A-C,E-I            8               8
       DMZ32        a-c,e-g           24               6
       DH11           h-o             16               8
       DHU11          S-Z             16               8
       pty            p-u             16               6
      

     |
     |
     |
     |
     |
     |
     |
     |
     |
     |








                                                            |
                                                            |
                                                            |
                                                            |
                                                            |
                                                            |
                                                            |

                                                            |
                                                            |













     To add a new terminal device, be  sure  the  device  is
configured  into  the  system and that the special files for
the device have been made by  /dev/MAKEDEV.   (For  example,
use  ``cd  /dev; MAKEDEV dz1'' to make the special files for
the second DZ11.) Then,  enable  the  appropriate  lines  of
/etc/ttys  by setting the ``status'' field to on (or add new
lines).  Note that lines in /etc/ttys are  one-for-one  with
entries in the file of current users (/etc/utmp), and there-
fore it is best to make changes while running in single-user
mode and to add all of the entries for a new device at once.

     The format of the /etc/ttys file is completely  new  in
4.3BSD.   Each  line  in  the  file  is broken into four tab
separated fields (comments are shown by a `#' character  and
extend  to the end of the line).  For each terminal line the
four fields are: the device (without a  leading  /dev),  the
program  /etc/init  should  startup  to service the line (or
none if the line is to be left  alone),  the  terminal  type
(found  in  /etc/termcap),  and  optional status information
describing if the terminal is enabled or not and  if  it  is
``secure''  (i.e.  the super user should be allowed to login
on the line).  All fields are character strings with entries
requiring  embedded  white  space enclosed in double quotes.
Thus a newly added terminal /dev/tty00 could be added as

        tty00   "/etc/getty std.9600"   vt100   on secure       # mike's office

The std.9600 parameter provided to  /etc/getty  is  used  in
searching  the file /etc/gettytab; it specifies a terminal's
characteristics (such as baud rate).  To make custom  termi-
nal    types,    consult    gettytab(5)   before   modifying
/etc/gettytab.

     Dialup terminals should be wired  so  that  carrier  is
asserted  only  when  the phone line is dialed up.  For non-
dialup terminals, from which modem control is not available,
you  must  either  wire back the signals so that the carrier
appears  to  always  be  present,  or  show  in  the  system



                      December 6, 2003





SMM:1-54ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


configuration  that  carrier  is to be assumed to be present
with flags for each terminal  device.   See  dh(4),  dhu(4),
dz(4), dmz(4), and dmf(4) for details.

     For network terminals (i.e. pseudo terminals), no  pro-
gram  should  be  started up on the lines.  Thus, the normal
entry in /etc/ttys would look like

        ttyp0   none    network

(Note, the fourth field is not needed here.)

     When the system is running  multi-user,  all  terminals
that  are listed in /etc/ttys as on have their line enabled.
If, during normal operations, you wish to disable a terminal
line,  you  can  edit  the  file  /etc/ttys  to  change  the
terminal's status to off and then send a  hangup  signal  to
the init process, by doing

        # kill -1 1

Terminals can similarly be enabled by  changing  the  status
field from off to on and sending a hangup signal to init.

     Note that if a special file is inaccessible  when  init
tries to create a process for it, init will log a message to
the system error logging process (/etc/syslogd) and  try  to
reopen  the  terminal  every  minute, reprinting the warning
message every 10 minutes.  Messages of this  sort  are  nor-
mally printed on the console, though other actions may occur
depending  on  the  configuration   information   found   in
/etc/syslog.conf.

     Finally note that you should change the  names  of  any
dialup  terminals  to  ttyd?   where ? is in [0-9a-zA-Z], as
some programs use this property of the names to determine if
a terminal is a dialup.  Shell commands to do this should be
put in the /dev/MAKEDEV.local script.

     While it is possible to use truly arbitrary strings for
terminal names, the accounting and noticeably the ps(1) com-
mand make good use of the  convention  that  tty  names  (by
default,  and  also  after  dialups  are  named as suggested
above) are distinct in the last 2  characters.  Change  this
and  you  may  be  sorry  later, as the heuristic ps(1) uses
based on these conventions will then break down and ps  will
run MUCH slower.

4.5.  Adding users

     The procedure for adding a new  user  is  described  in
adduser(8).   You  should  add accounts for the initial user
community, giving each a directory and a password, and  put-
ting  users  who  will  wish  to  share software in the same



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX55


groups.

     Several guest accounts have been provided on  the  dis-
tribution system; these accounts are for people at Berkeley,
Bell Laboratories, and others who have done  major  work  on
UNIX  in  the past.  You can delete these accounts, or leave
them on the system if you expect  that  these  people  would
have occasion to login as guests on your system.

4.6.  Site tailoring

     All programs that require  the  site's  name,  or  some
similar  characteristic, obtain the information through sys-
tem calls or from files located in /etc.  Aside  from  parts
of  the  system related to the network, to tailor the system
to your site you must simply select a site name,  then  edit
the file

        /etc/netstart

The first lines in /etc/netstart use a variable to  set  the
hostname,

        hostname=mysitename
        /bin/hostname $hostname

to define the value returned by  the  gethostname(2)  system
call.   If  you  are running the name server, your site name
should be your fully qualified domain name.   Programs  such
as  getty(8),  mail(1), wall(1), and uucp(1) use this system
call so that the binary images are site independent.

4.7.  Setting up the line printer system

     The line printer system consists of at least  the  fol-
lowing files and commands:


        /usr/ucb/lpq     spooling queue examination program
        /usr/ucb/lprm    program to delete jobs from a queue
        /usr/ucb/lpr     program to enter a job in a printer queue
        /etc/printcap    printer configuration and capability data base
        /usr/lib/lpd     line printer daemon, scans spooling queues
        /etc/lpc         line printer control program
        /etc/hosts.lpd   list of host allowed to use the printers



     The file /etc/printcap is a master data base describing
line  printers  directly  attached  to  a machine and, also,
printers accessible  across  a  network.   The  manual  page
printcap(5)  describes the format of this data base and also
shows the default values for such things as the directory in
which  spooling  is  performed.   The  line  printer  system



                      December 6, 2003





SMM:1-56ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


handles multiple printers, multiple spooling  queues,  local
and  remote  printers, and also printers attached via serial
lines that require line  initialization  such  as  the  baud
rate.   Raster  output devices such as a Varian or Versatec,
and laser printers such as an Imagen, are also supported  by
the line printer system.

     Remote spooling via the network  is  handled  with  two
spooling  queues,  one  on  the local machine and one on the
remote machine.  When a remote printer job is  started  with
lpr,  the job is queued locally and a daemon process created
to oversee the transfer of the job to  the  remote  machine.
If  the  destination  machine  is  unreachable, the job will
remain queued until it is possible to transfer the files  to
the  spooling  queue on the remote machine.  The lpq program
shows the contents of spool queues on  both  the  local  and
remote machines.

     To configure your line printers, consult  the  printcap
manual  page  and  the  accompanying document, ``4.3BSD Line
Printer Spooler Manual''.  A call to the lpd program  should
be present in /etc/rc.

4.8.  Setting up the mail system

     The mail system consists of the following commands:


        /bin/mail               old standard mail program, described in binmail(1)
        /usr/ucb/mail           UCB mail program, described in mail(1)
        /usr/lib/sendmail       mail routing program
        /usr/spool/mail         mail spooling directory
        /usr/spool/secretmail   secure mail directory
        /usr/bin/xsend          secure mail sender
        /usr/bin/xget           secure mail receiver
        /usr/lib/aliases        mail forwarding information
        /usr/ucb/newaliases     command to rebuild binary forwarding database
        /usr/ucb/biff           mail notification enabler
        /etc/comsat             mail notification daemon


Mail is normally sent and received using the mail(1) command
(found in /usr/ucb/mail), which provides a front-end to edit
the messages sent and received, and passes the  messages  to
sendmail(8)   for   routing.   The  routing  algorithm  uses
knowledge of the network name syntax, aliasing and  forward-
ing  information,  and  network  topology, as defined in the
configuration file  /usr/lib/sendmail.cf,  to  process  each
piece  of mail.  Local mail is delivered by giving it to the
program /bin/mail that adds  it  to  the  mailboxes  in  the
directory /usr/spool/mail/username, using a locking protocol
to avoid problems with simultaneous updates.  After the mail
is  delivered, the local mail delivery daemon /etc/comsat is
notified, which in turn notifies users  who  have  issued  a



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX57


``biff y'' command that mail has arrived.

     Mail queued in the directory  /usr/spool/mail  is  nor-
mally  readable only by the recipient.  To send mail that is
secure against perusal (except by a code-breaker) you should
use the secret mail facility, which encrypts the mail.

     To set  up  the  mail  facility  you  should  read  the
instructions   in   the   file   READ ME  in  the  directory
/usr/src/usr.lib/sendmail and then adjust the necessary con-
figuration   files.    You  should  also  set  up  the  file
/usr/lib/aliases for your installation, creating mail groups
as  appropriate.   Documents describing sendmail's operation
and installation are also included in the distribution.

4.8.1.  Setting up a UUCP connection

     The version of uucp included in 4.3BSD-Quasijarus is  a
greatly  enhanced  version of the one originally distributed
with 32/V*.  The enhancements include:

o  support for many auto call units and dialers in  addition
   to the DEC DN11,

o  breakup of the  spooling  area  into  multiple  subdirec-
   tories,

o  addition of an L.cmds file to control the set of commands
   that may be executed by a remote site,

o  enhanced ``expect-send'' sequence capabilities when  log-
   ging in to a remote site,

o  new commands to be used in polling  sites  and  obtaining
   snap shots of uucp activity,

o  additional protocols for different communication media.

This section gives a brief overview of uucp and  points  out
the most important steps in its installation.

     To connect two UNIX machines with a uucp  network  link
using  modems, one site must have an automatic call unit and
the other must have a dialup port.  It  is  better  if  both
sites have both.

     You should first read the  paper  in  the  UNIX  System
Manager's  Manual:  ``Uucp Implementation Description''.  It

* The uucp included in this distribution is the  result
of work by many people; we gratefully acknowledge their
contributions, but refrain from mentioning names in the
interest of keeping this document current.




                      December 6, 2003





SMM:1-58ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


describes in detail the file formats  and  conventions,  and
will  give  you a little context.  In addition, the document
``setup.tblms'',     located      in      the      directory
/usr/src/usr.bin/uucp/UUAIDS, may be of use in tailoring the
software to your needs.

     The uucp support is located in three major directories:
/usr/bin, /usr/lib/uucp, and /usr/spool/uucp.  User commands
are kept in /usr/bin, operational commands in /usr/lib/uucp,
and  /usr/spool/uucp  is  used as a spooling area.  The com-
mands in /usr/bin are:


        /usr/bin/uucp       file-copy command
        /usr/bin/uux        remote execution command
        /usr/bin/uusend     binary file transfer using mail
        /usr/bin/uuencode   binary file encoder (for uusend)
        /usr/bin/uudecode   binary file decoder (for uusend)
        /usr/bin/uulog      scans session log files
        /usr/bin/uusnap     gives a snap-shot of uucp activity
        /usr/bin/uupoll     polls remote system until an answer is received
        /usr/bin/uuname     prints a list of known uucp hosts
        /usr/bin/uuq        gives information about the queue


The important files and commands in /usr/lib/uucp are:


        /usr/lib/uucp/L-devices     list of dialers and hard-wired lines
        /usr/lib/uucp/L-dialcodes   dialcode abbreviations
        /usr/lib/uucp/L.aliases     hostname aliases
        /usr/lib/uucp/L.cmds        commands remote sites may execute
        /usr/lib/uucp/L.sys         systems to communicate with, how to connect, and when
        /usr/lib/uucp/SEQF          sequence numbering control file
        /usr/lib/uucp/USERFILE      remote site pathname access specifications
        /usr/lib/uucp/uucico        uucp protocol daemon
        /usr/lib/uucp/uuclean       cleans up garbage files in spool area
        /usr/lib/uucp/uuxqt         uucp remote execution server


while the spooling area  contains  the  following  important
files and directories:


        /usr/spool/uucp/C.           directory for command, ``C.'' files
        /usr/spool/uucp/D.           directory for data, ``D.'', files
        /usr/spool/uucp/X.           directory for command execution, ``X.'', files
        /usr/spool/uucp/D.machine    directory for local ``D.'' files
        /usr/spool/uucp/D.machineX   directory for local ``X.'' files
        /usr/spool/uucp/TM.          directory for temporary, ``TM.'', files
        /usr/spool/uucp/LOGFILE      log file of uucp activity
        /usr/spool/uucp/SYSLOG       log file of uucp file transfers





                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX59


     To install uucp on your system, start  by  selecting  a
site  name (shorter than 14 characters). A uucp account must
be created in the password  file  and  a  password  set  up.
Then,  create the appropriate spooling directories with mode
755 and owned by user uucp, group daemon.

     If you have an auto-call unit, the L.sys,  L-dialcodes,
and  L-devices  files  should  be  created.   The L.sys file
should  contain  the  phone  numbers  and  login   sequences
required  to  establish  a  connection with a uucp daemon on
another machine.  For example, our L.sys  file  looks  some-
thing like:

        adiron Any ACU 1200 out0123456789- ogin-EOT-ogin uucp
        cbosg Never Slave 300
        cbosgd Never Slave 300
        chico Never Slave 1200 out2010123456

The first field is the name of a site, the second shows when
the machine may be called, the third field specifies how the
host is connected (through an ACU, a hard-wired line, etc.),
then  comes the phone number to use in connecting through an
auto-call unit, and finally a  login  sequence.   The  phone
number  may contain common abbreviations that are defined in
the L-dialcodes file.  The device specification should refer
to  devices  specified  in the L-devices file.  Listing only
ACU causes the uucp daemon, uucico, to search for any avail-
able  auto-call  unit in L-devices.  Our L-dialcodes file is
of the form:

        ucb 2
        out 9%

while our L-devices file is:

        ACU cul0 unused 1200 ventel

Refer to the README file in the uucp  source  directory  for
more information about installation.

     As uucp operates it creates (and  removes)  many  small
files  in the directories underneath /usr/spool/uucp.  Some-
times files are left undeleted; these are most easily purged
with  the  uuclean  program.  The log files can grow without
bound unless trimmed  back;  uulog  maintains  these  files.
Many  useful  aids in maintaining your uucp installation are
included    in     a     subdirectory     UUAIDS     beneath
/usr/src/usr.bin/uucp.   Peruse  this directory and read the
``setup'' instructions also located there.








                      December 6, 2003





SMM:1-60ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


                      5. NETWORK SETUP



     4.3BSD provides support for the DARPA standard Internet
protocols  IP,  ICMP,  TCP, and UDP.  These protocols may be
used on top of a variety of hardware  devices  ranging  from
the  IMP's (PSN's) used in the ARPANET to local area network
controllers for the Ethernet.  Network  services  are  split
between  the  kernel (communication protocols) and user pro-
grams (user services such as TELNET and FTP).  This  section
describes  how  to configure your system to use the Internet
networking support.  4.3BSD also supports the Xerox  Network
Systems  (NS) protocols.  IDP and SPP are implemented in the
kernel, and other protocols such as Courier run at the  user
level.

5.1.  System configuration

     To configure the kernel to include the Internet commun-
ication protocols, define the INET option.  Xerox NS support
is enabled with the NS option.  In either case, include  the
pseudo-devices  ``pty'', and ``loop'' in your machine's con-
figuration file. The ``pty'' pseudo-device forces the pseudo
terminal device driver to be configured into the system, see
pty(4), while the ``loop'' pseudo-device forces inclusion of
the  software loopback interface driver.  The loop driver is
used in network testing and also by the error  logging  sys-
tem.

     If you are planning to use the Internet network facili-
ties  on  a  10Mb/s  Ethernet,  the  pseudo-device ``ether''
should also be included in the  configuration;  this  forces
inclusion  of the Address Resolution Protocol module used in
mapping  between  48-bit  Ethernet   and   32-bit   Internet
addresses.   Also,  if  you have an IMP connection, you will
need to include the pseudo-device ``imp.''

     Before configuring the appropriate networking hardware,
you  should  consult  the  manual  pages in section 4 of the
Programmer's Manual.  The following table lists the  devices
for which software support exists.















                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX61




        Device name   Manufacturer and product
        

        acc           ACC LH/DH interface to IMP
        css           DEC IMP-11A interface to IMP
        ddn           ACC ACP625 DDN Standard mode X.25 interface to IMP
        dmc           DEC DMC-11 (also works with DMR-11)
        de            DEC DEUNA 10Mb/s Ethernet
        ec            3Com 10Mb/s Ethernet
        en            Xerox 3Mb/s prototype Ethernet (not a product)
        ex            Excelan 204 10Mb/s Ethernet
        hdh           ACC IF-11/HDH IMP interface
        hy            NSC Hyperchannel, w/ DR-11B and PI-13 interfaces
        il            Interlan 1010 and 10101A 10Mb/s Ethernet interfaces
        ix            Interlan NP100 10Mb/s Ethernet interface
        pcl           DEC PCL-11
        vv            Proteon 10Mb/s and 80Mb/s proNET ring network (V2LNI)



     All network interface drivers  including  the  loopback
interface, require that their host address(es) be defined at
boot time.  This is done with ifconfig(8C) commands included
in  the  /etc/netstart  file.   Interfaces  that are able to
dynamically deduce the host part of  an  address  may  check
that  the  host  part of the address is correct.  The manual
page for each network interface describes the method used to
establish  a  host's address.  Ifconfig(8C) can also be used
to set options for the interface at boot time.  Options  are
set independently for each interface, and apply to all pack-
ets sent using that interface.  These options include  disa-
bling  the  use of the Address Resolution Protocol; this may
be useful if a network is shared with hosts running software
that  does  not  yet  provide this function.  Alternatively,
translations for such hosts may be set in advance or  ``pub-
lished''  by  a  4.3BSD  host by use of the arp(8C) command.
Note that the use of trailer link-level  is  now  negotiated
between  4.3BSD  hosts  using  ARP, and it is thus no longer
necessary to disable the use of trailers with ifconfig.

     To use the pseudo  terminals  just  configured,  device
entries must be created in the /dev directory.  To create 32
pseudo terminals (plenty, unless you have  a  heavy  network
load) execute the following commands.

        # cd /dev
        # MAKEDEV pty0 pty1

More pseudo terminals may be made by specifying pty2,  pty3,
etc.   The  kernel  normally  includes support for 32 pseudo
terminals unless the configuration  file  specifies  a  dif-
ferent  number.  Each pseudo terminal really consists of two
files in /dev: a master and  a  slave.   The  master  pseudo



                      December 6, 2003





SMM:1-62ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


terminal  file  is named /dev/ptyp?, while the slave side is
/dev/ttyp?.  Pseudo terminals are also used by several  pro-
grams  not  related to the network.  In addition to creating
the pseudo  terminals,  be  sure  to  install  them  in  the
/etc/ttys  file  (with  a  `none' in the second column so no
getty is started).

5.2.  Local subnets

     In 4.3BSD  the  DARPA  Internet  support  includes  the
notion  of ``subnets''.  This is a mechanism by which multi-
ple local networks may appears as a single Internet  network
to  off-site  hosts.   Subnetworks  are  useful because they
allow a site to hide their local topology, requiring only  a
single  route in external gateways; it also means that local
network numbers may be locally administered.   The  standard
describing this change in Internet addressing is RFC-950.

     To set up local subnets one must first decide  how  the
available  address  space (the Internet ``host part'' of the
32-bit address) is to be partitioned.  Sites with a class  A
network  number  have a 24-bit host address space with which
to work, sites with a class B network number have  a  16-bit
host  address  space,  while  sites  with  a class C network
number have an 8-bit host address space.*  To  define  local
subnets you must steal some bits from the local host address
space for use in extending the network portion of the Inter-
net address.  This reinterpretation of Internet addresses is
done only for local networks; i.e.  it  is  not  visible  to
hosts  off-site.   For  example,  if your site has a class B
network number, hosts  on  this  network  have  an  Internet
address  that  contains the network number, 16 bits, and the
host number, another 16 bits.  To define 254 local  subnets,
each  possessing at most 255 hosts, 8 bits may be taken from
the local part.  (The use of subnets 0 and all-1's,  255  in
this example, is discouraged to avoid confusion about broad-
cast addresses.) These new network  numbers  are  then  con-
structed by concatenating the original 16-bit network number
with the extra 8 bits containing the local subnet number.

     The existence of local subnets is communicated  to  the
system  at  the  time a network interface is configured with
the netmask option to the  ifconfig  program.   A  ``network
mask''  is  specified  to define the portion of the Internet
address that is to be considered the network part  for  that
network.  This mask normally contains the bits corresponding
to the standard network part as well as the portion  of  the
local part that has been assigned to subnets.  If no mask is

* If you are unfamiliar with  the  Internet  addressing
structure,  consult ``Address Mappings'', Internet RFC-
796, J. Postel; available from the Internet Network In-
formation Center at SRI.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX63


specified when the address is set, it will be set  according
to  the  class  of  the  network.   For example, at Berkeley
(class B network 128.32) 8 bits of the local part have  been
reserved    for    defining    subnets;   consequently   the
/etc/netstart file contains lines of the form

        /etc/ifconfig en0 netmask 0xffffff00 128.32.1.7

This specifies that for interface ``le0'', the upper 24 bits
of  the  Internet address should be used in calculating net-
work  numbers  (netmask  0xffffff00),  and  the  interface's
Internet  address  is  ``128.32.1.7''  (host  7  on  network
128.32.1).  Hosts m on sub-network n of this  network  would
then  have  addresses of the form ``128.32.n.m'';  for exam-
ple,  host  99  on  network  129  would  have   an   address
``128.32.129.99''.   For hosts with multiple interfaces, the
network mask should be set for each interface,  although  in
practice  only  the mask of the first interface on each net-
work is actually used.

5.3.  Internet broadcast addresses

     The address defined as the broadcast address for Inter-
net networks according to RFC-919 is the address with a host
part of all 1's.  The address used by 4.2BSD was the address
with  a  host part of 0.  4.3BSD uses the standard broadcast
address (all 1's)  by  default,  but  allows  the  broadcast
address  to be set (with ifconfig) for each interface.  This
allows networks consisting of both 4.2BSD and  4.3BSD  hosts
to coexist while the upgrade process proceeds.  In the pres-
ence of subnets, the broadcast address uses the subnet field
as  for  normal host addresses, with the remaining host part
set to 1's (or 0's, on a network that has not yet been  con-
verted).   4.3BSD hosts recognize and accept packets sent to
the logical-network broadcast address as well as those  sent
to  the  subnet broadcast address, and when using an all-1's
broadcast, also recognize and receive packets sent to host 0
as a broadcast.

5.4.  Routing

     If your  environment  allows  access  to  networks  not
directly attached to your host you will need to set up rout-
ing information to allow packets to be properly routed.  Two
schemes  are  supported  by  the  system.   The first scheme
employs the routing table management daemon  /etc/routed  to
maintain the system routing tables.  The routing daemon uses
a variant of the Xerox Routing Information Protocol to main-
tain  up  to  date routing tables in a cluster of local area
networks.   By  using  the  /etc/gateways  file  created  by
htable(8), the routing daemon can also be used to initialize
static routes to distant networks (see the next section  for
further  discussion).  When the routing daemon is started up
(usually from /etc/rc) it reads /etc/gateways if  it  exists



                      December 6, 2003





SMM:1-64ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


and  installs those routes defined there, then broadcasts on
each local network to which the host  is  attached  to  find
other instances of the routing daemon.  If any responses are
received, the routing daemons  cooperate  in  maintaining  a
globally  consistent  view  of routing in the local environ-
ment.  This view can be extended  to  include  remote  sites
also  running  the  routing  daemon  by  setting up suitable
entries in /etc/gateways;  consult  routed(8C)  for  a  more
thorough discussion.

     The second approach is to define a default or  wildcard
route  to  a smart gateway and depend on the gateway to pro-
vide ICMP routing redirect information to dynamically create
a routing data base.  This is done by adding an entry of the
form

        /etc/route add default smart-gateway 1

to /etc/netstart; see route(8C) for more  information.   The
default  route  will  be  used  by  the  system  as a ``last
resort'' in routing packets to their destination.   Assuming
the  gateway  to  which packets are directed is able to gen-
erate the proper routing redirect messages, the system  will
then add routing table entries based on the information sup-
plied.  This approach has certain advantages over the  rout-
ing  daemon, but is unsuitable in an environment where there
are only bridges (i.e.  pseudo gateways that, for  instance,
do not generate routing redirect messages).  Further, if the
smart gateway goes down there is no alternative, save manual
alteration  of  the routing table entry, to maintaining ser-
vice.

     The  system  always  listens,  and  processes,  routing
redirect  information,  so it is possible to combine both of
the  above  facilities.   For  example,  the  routing  table
management  process  might  be  used  to maintain up to date
information about routes to geographically  local  networks,
while  employing  the wildcard routing techniques for ``dis-
tant'' networks.  The netstat(1)  program  may  be  used  to
display  routing  table  contents as well as various routing
oriented statistics.  For example,

        # netstat -r

will display the contents of the routing tables, while

        # netstat -r -s

will show the number of routing  table  entries  dynamically
created as a result of routing redirect messages, etc.

5.5.  Use of 4.3BSD machines as gateways

     Several changes have been made in 4.3BSD in the area of



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX65


gateway  support  (or packet forwarding, if one prefers).  A
new configuration option, GATEWAY, is used when  configuring
a  machine  to  be used as a gateway.  This option increases
the size of the routing hash tables in the  kernel.   Unless
configured  with  that option, hosts with only a single non-
loopback interface never attempt to forward  packets  or  to
respond  with  ICMP  error  messages to misdirected packets.
This change reduces the problems that may  occur  when  dif-
ferent  hosts on a network disagree as to the network number
or  broadcast  address.   Another  change  is  that   4.3BSD
machines  that  forward packets back through the same inter-
face on which they arrived will send ICMP redirects  to  the
source host if it is on the same network.  This improves the
interaction of 4.3BSD gateways  with  hosts  that  configure
their  routes  via default gateways and redirects.  The gen-
eration of redirects may be disabled with the  configuration
option  IPSENDREDIRECTS=0 in environments where it may cause
difficulties.

     Local area routing within  a  group  of  interconnected
Ethernets   and  other  such  networks  may  be  handled  by
routed(8C).  Gateways between the Arpanet or Milnet and  one
or  more local networks require an additional routing proto-
col, the Exterior Gateway Protocol (EGP), to inform the core
gateways  of  their presence and to acquire routing informa-
tion from the core.  An EGP  implementation  for  4.3BSD  is
available  by  anonymous  ftp from ucbarpa.berkeley.edu.  If
necessary, contact the Berkeley  Computer  Systems  Research
Group for assistance.

5.6.  Network data bases

     Several data files are used by the network library rou-
tines  and  server  programs.   Most of these files are host
independent and updated only rarely.


        File               Manual reference   Use
        

        /etc/hosts         hosts(5)           host names
        /etc/networks      networks(5)        network names
        /etc/services      services(5)        list of known services
        /etc/protocols     protocols(5)       protocol names
        /etc/hosts.equiv   rshd(8C)           list of ``trusted'' hosts
        /etc/netstart      rc(8)              command script for initializing network
        /etc/rc            rc(8)              command script for starting standard servers
        /etc/rc.local      rc(8)              command script for starting local servers
        /etc/ftpusers      ftpd(8C)           list of ``unwelcome'' ftp users
        /etc/hosts.lpd     lpd(8C)            list of hosts allowed to access printers
        /etc/inetd.conf    inetd(8)           list of servers started by inetd


The files distributed are set up for ARPANET or other Inter-
net  hosts.   Local  networks  and  hosts should be added to



                      December 6, 2003





SMM:1-66ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


describe the local configuration; the Berkeley  entries  may
serve  as  examples (see also the section on on /etc/hosts).
Network numbers will have to be chosen  for  each  Ethernet.
For  sites  connected  to  the Internet, the normal channels
should be used for allocation of  network  numbers  (contact
hostmaster@SRI-NIC.ARPA).   For  other sites, these could be
chosen more or less arbitrarily, but it is generally  better
to request official numbers to avoid conversion if a connec-
tion to the Internet (or others on  the  Internet)  is  ever
established.

5.6.1.  Network servers

     Most network servers are automatically  started  up  at
boot  time  by  the  command file /etc/rc or by the Internet
daemon (see below).  These include the following:


        Program             Server                            Started by
        

        /etc/syslogd        error logging server              /etc/rc
        /etc/named          Internet name server              /etc/rc
        /etc/routed         routing table management daemon   /etc/rc
        /etc/rwhod          system status daemon              /etc/rc
        /etc/timed          time synchronization daemon       /etc/rc.local
        /usr/lib/sendmail   SMTP server                       /etc/rc.local
        /etc/rshd           shell server                      inetd
        /etc/rexecd         exec server                       inetd
        /etc/rlogind        login server                      inetd
        /etc/telnetd        TELNET server                     inetd
        /etc/ftpd           FTP server                        inetd
        /etc/fingerd        Finger server                     inetd
        /etc/tftpd          TFTP server                       inetd


Consult the  manual  pages  and  accompanying  documentation
(particularly  for  named  and  sendmail)  for details about
their operation.

     The use of routed and  rwhod  is  controlled  by  shell
variables set in /etc/netstart.  By default, routed is used,
but rwhod is not; they are enabled by setting the  variables
routedflags  and  rwhod  to  strings  other than ``NO.'' The
value  of  routedflags  is  used  to  provide  host-specific
options to routed.  For example,

        routedflags=-q
        rwhod=NO

would run routed -q and would not run rwhod.

     To have other network servers started as well, commands
of the following sort should be placed in the site-dependent
file /etc/rc.local.



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX67



        if [ -f /etc/timed ]; then
                /etc/timed & echo -n ' timed'                   >/dev/console
        fi


5.6.2.  Internet daemon

     In 4.3BSD most of the servers for user-visible services
are  started  up by a ``super server'', the Internet daemon.
The Internet daemon, /etc/inetd, acts as a master server for
programs    specified    in    its    configuration    file,
/etc/inetd.conf, listening for service  requests  for  these
servers,  and starting up the appropriate program whenever a
request is received.  The configuration file contains  lines
containing  a  service name (as found in /etc/services), the
type of socket the server expects (e.g.  stream  or  dgram),
the  protocol  to  be  used  with  the  socket  (as found in
/etc/protocols), whether to wait for each server to complete
before  starting  up  another,  the  user  name as which the
server should run, the server program's name,  and  at  most
five  arguments to pass to the server program.  Some trivial
services are implemented  internally  in  inetd,  and  their
servers  are  listed  as ``internal.'' For example, an entry
for the file transfer protocol server would appear as

        ftp     stream  tcp     nowait  root    /etc/ftpd       ftpd

Consult inetd(8C) for more detail on the format of the  con-
figuration file and the operation of the Internet daemon.

5.6.3.  Regenerating /etc/hosts and /etc/networks

     When using the  host  address  routines  that  use  the
Internet  name  server, the file /etc/hosts is only used for
setting interface addresses and  at  other  times  that  the
server  is  not  running, and therefore it need only contain
addresses for local hosts.  There is no  equivalent  service
for  network names yet.  The full host and network name data
bases are normally derived from a file  retrieved  from  the
Internet  Network Information Center at SRI.  To do this you
should use the program /etc/gettable  to  retrieve  the  NIC
host  data  base, and the program htable(8) to convert it to
the format used by the libraries.  You should change to  the
directory  where  you  maintain  your local additions to the
host table and execute the following commands.

        # /etc/gettable sri-nic.arpa
        Connection to sri-nic.arpa opened.
        Host table received.
        Connection to sri-nic.arpa closed.
        # /etc/htable hosts.txt
        Warning, no localgateways file.
        #



                      December 6, 2003





SMM:1-68ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


The htable program generates three files in the local direc-
tory:   hosts,   networks   and   gateways.    If   a   file
``localhosts'' is present in the working directory its  con-
tents  are  first  copied  to the output file.  Similarly, a
``localnetworks''  file  may  be  prepended  to  the  output
created by htable, and `localgateways'' will be prepended to
gateways.  It is usually wise to run diff(1) on the new host
and  network  data bases before installing them in /etc.  If
you are using the host table for host name and address  map-
ping, you should run mkhosts(8) after installing /etc/hosts.
If you are using the name  server  for  the  host  name  and
address  mapping,  you  only  need to install networks and a
small copy of hosts describing  your  local  machines.   The
full  host table in this case might be placed somewhere else
for reference by users.  The gateways file may be  installed
in /etc/gateways if you use routed(8C) for local routing and
wish to have static external routes installed when routed is
started.   This  procedure is essentially obsolete, however,
except for individual hosts that are on the Arpanet or  Mil-
net  and do not forward packets from a local network.  Other
situations require the use of an EGP server.

     If you are connected  to  the  DARPA  Internet,  it  is
highly  recommended  that  you  use the name server for your
host name and address mapping, as this provides access to  a
much  larger  set  of  hosts  than  are provided in the host
table.  Many large organizations on  the  network  currently
have  only  a  small percentage of their hosts listed in the
host table retrieved from NIC.

5.6.4.  /etc/hosts.equiv

     The remote login and shell servers use  an  authentica-
tion  scheme  based  on trusted hosts.  The hosts.equiv file
contains a list of hosts that are  considered  trusted  and,
under a single administrative control.  When a user contacts
a remote login  or  shell  server  requesting  service,  the
client  process passes the user's name and the official name
of the host on which the client is located.  In  the  simple
case,  if  the host's name is located in hosts.equiv and the
user has an account on the server's machine, then service is
rendered (i.e. the user is allowed to log in, or the command
is executed).  Users  may  expand  this  ``equivalence''  of
machines  by installing a .rhosts file in their login direc-
tory.  The root login is handled  specially,  bypassing  the
hosts.equiv file, and using only the /.rhosts file.

     Thus, to create a class  of  equivalent  machines,  the
hosts.equiv file should contain the official names for those
machines.  If you are running the name server, you may  omit
the  domain part of the host name for machines in your local
domain.  For example, four machines on our local network are
considered trusted, so the hosts.equiv file is of the form:




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX69



        ucbarpa
        okeeffe
        monet
        ucbvax


5.6.5.  /etc/ftpusers

     The FTP server included in the system provides  support
for an anonymous FTP account.  Because of the inherent secu-
rity problems with such a facility you should read this sec-
tion carefully if you consider providing such a service.

     An anonymous account is enabled by creating a user ftp.
When  a client uses the anonymous account a chroot(2) system
call is performed by the server to restrict the client  from
moving  outside  that part of the file system where the user
ftp home directory is located.  Because  a  chroot  call  is
used,  certain programs and files used by the server process
must be placed in the ftp home directory. Further, one  must
be  sure  that  all  directories  and  executable images are
unwritable.  The following directory setup  is  recommended.
The  use  of  the  awk  commands to copy the /etc/passwd and
/etc/group files are STRONGLY recommended.

        # cd ~ftp
        # chmod 555 .; chown ftp .; chgrp ftp .
        # mkdir bin etc pub
        # chown root bin etc
        # chmod 555 bin etc
        # chown ftp pub
        # chmod 777 pub
        # cd bin
        # cp /bin/sh /bin/ls .
        # chmod 111 sh ls
        # cd ../etc
        # awk -F: '{$2="*";print$1":"$2":"$3":"$4":"$5":"$6":"}' < /etc/passwd > passwd
        # awk -F: '{$2="*";print$1":"$2":"}' < /etc/group > group
        # chmod 444 passwd group

When local users wish to place files in the anonymous  area,
they  must  be placed in a subdirectory.  In the setup here,
the directory ~ftp/pub is used.

     Aside from the problems of directory  modes  and  such,
the  ftp  server  may  provide a loophole for interlopers if
certain user accounts are allowed.  The  file  /etc/ftpusers
is  checked  on each connection.  If the requested user name
is located in the file, the request for service  is  denied.
This file normally has the following names on our systems.

        uucp
        root



                      December 6, 2003





SMM:1-70ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


Accounts without passwords need not be listed in  this  file
as  the  ftp  server  will  refuse  service  to these users.
Accounts  with  nonstandard  shells  (any  not   listed   in
/etc/shells) will also be denied access via ftp.





















































                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX71


                    6. SYSTEM OPERATION



     This section describes procedures  used  to  operate  a
4.3BSD-Quasijarus  UNIX  system.   Procedures described here
are used periodically, to reboot the system,  analyze  error
messages  from devices, do disk backups, monitor system per-
formance,  recompile  system  software  and  control   local
changes.

6.1.  Bootstrap and shutdown procedures

     In a normal reboot, the system  checks  the  disks  and
comes  up  multi-user  without  intervention at the console.
Such a reboot can be stopped (after it prints the date) with
a ^C (interrupt).  This will leave the system in single-user
mode, with only the console terminal  active.   It  is  also
possible to allow the filesystem checks to complete and then
to return to single-user mode by signaling  fsck(8)  with  a
QUIT signal (^\).

     If booting from the console command  level  is  needed,
then the command

        >>>B

will boot from the default device.  On an 8600,  11/780,  or
11/730  the  default  device  is determined by a ``DEPOSIT''
command stored on  the  console  boot  device  in  the  file
``DEFBOO.CMD'' (``DEFBOO.COM'' on an 8600); on an 11/750 the
default device is determined by the setting of a  switch  on
the  front panel; on an 8200 the default device is stored in
EEPROM.  On 11/750 and 8200 the default boot device  may  be
set  to  the console storage device (TU58 on 750 and RX50 on
8200).  In this case there must be  a  console  medium  with
BOOT58 in the console storage device, and the boot procedure
and system disk are determined by  the  ``DEFBOO.CMD''  boot
script  stored  on the console medium.  On MicroVAX 3/3+ the
default boot device is stored in NVRAM and  set  with  ``SET
BOOT'' console command.  MicroVAX II does not allow the boot
device to be selected, it always boots from the first  boot-
able disk in the system.

     You can boot a system up single user on an  8600,  780,
or 730 by doing

        >>>B xxS

where xx is one of HP, HK, UP, RA, or RB.  The corresponding
command  on  an  11/750  or  8200  booting without a console
medium, or for a MicroVAX is

        >>>B/2



                      December 6, 2003





SMM:1-72ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


On an 8200 using the console floppy, use

        >>>B/R5:800
        (node and memory test values)
        BOOT58> @SNGBOO.CMD


     For second vendor storage  modules  on  the  UNIBUS  or
MASSBUS  of  an  11/750  you  will need to have a boot prom.
Most vendors will sell you such proms for their controllers;
contact  your  vendor if you don't have one.  Alternatively,
you could set up a BOOT58-based boot path.   Contact  Quasi-
jarus Consortium for assistance.

     Other possibilities are:

        >>>B ANY

or, on an 8200 using the console floppy,

        >>>B/R5:800
        BOOT58>@ANYBOO.CMD

or, on an 11/750 or a MicroVAX

        >>>B/3

These commands boot and ask for the name of the system to be
booted.   They  can be used after building a new test system
to give the boot program the name of the test version of the
system.*

     To bring the system up to  a  multi-user  configuration
from the single-user status, all you have to do is hit ^D on
the console.   The  system  will  then  execute  /etc/rc,  a
multi-user  restart  script (and /etc/rc.local), and come up
on the terminals listed as active  in  the  file  /etc/ttys.
See  init(8)  and  ttys(5) for more details.  Note, however,
that this does not cause a file  system  check  to  be  per-
formed.   Unless  the  system  was  taken  down cleanly, you
should run ``fsck -p'' or force a reboot with  reboot(8)  to
have the disks checked.

     To take the system down to a single user state you  can
use

        # kill 1

or use the shutdown(8) command (which is much  more  polite,

* Additional bootflags are used when a system  is  con-
figured  with  the  kernel debugger; consult kdb(4) for
details.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX73


if there are other users logged in)  when  you  are  running
multi-user.  Either command will kill all processes and give
you a shell on the console, as if you had just booted.  File
systems  remain  mounted  after  the system is taken single-
user.  If you wish to come up multi-user again,  you  should
do this by:

        # cd /
        # /etc/umount -a
        # ^D


     Each system shutdown, crash, processor halt and  reboot
is recorded in the system log with its cause.

6.2.  Device errors and diagnostics

     When serious errors occur on peripherals or in the sys-
tem,  the system prints a warning diagnostic on the console.
These messages are collected by  the  system  error  logging
process  syslogd(8) and written into a system error log file
/usr/adm/messages.  Less serious errors are sent directly to
syslogd,  which  may  log  them  on  the console.  The error
priorities that are logged and the locations to  which  they
are  logged  are  controlled  by /etc/syslog.conf.  See sys-
logd(8) for further details.

     Error messages printed by the devices in the system are
described  with  the drivers for the devices in section 4 of
the  programmer's  manual.   If  errors   occur   suggesting
hardware  problems, you should contact your hardware support
group or field service.  It is a good idea  to  examine  the
error  log  file  regularly  (e.g.  with the command tail -r
/usr/adm/messages).

6.3.  File system checks, backups and disaster recovery

     Periodically (say every week or so in  the  absence  of
any  problems)  and  always  (usually automatically) after a
crash, all the file  systems  should  be  checked  for  con-
sistency  by fsck(1).  The procedures of reboot(8) should be
used to get the system to a state where a file system  check
can be performed manually or automatically.

     Dumping of the file systems should be  done  regularly,
since  once the system is going it is easy to become compla-
cent.  Complete and incremental dumps are easily  done  with
dump(8).   You  should  arrange to do a towers-of-hanoi dump
sequence; we tune ours so that almost all files  are  dumped
on  two  tapes  and  kept  for at least a week in most every
case.  We take full dumps every month (and keep these  inde-
finitely).   Operators  can execute ``dump w'' at login that
will tell them  what  needs  to  be  dumped  (based  on  the
/etc/fstab information).  Be sure to create a group operator



                      December 6, 2003





SMM:1-74ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


in the file /etc/group so that  dump  can  notify  logged-in
operators when it needs help.

     More precisely, we have three sets of  dump  tapes:  10
daily  tapes,  5  weekly  sets of 2 tapes, and fresh sets of
three tapes monthly.  We do daily dumps  circularly  on  the
daily tapes with sequence `3 2 5 4 7 6 9 8 9 9 9 ...'.  Each
weekly is a level 1 and the daily dump sequence  level  res-
tarts  after  each  weekly dump.  Full dumps are level 0 and
the daily sequence restarts after each full dump also.

     Thus a typical dump sequence would be:

    tape name   level number       date       opr   size
    

      FULL           0         Nov 24, 1979   jkf   137K
        D1           3         Nov 28, 1979   jkf   29K
        D2           2         Nov 29, 1979   rrh   34K
        D3           5         Nov 30, 1979   rrh   19K
        D4           4          Dec 1, 1979   rrh   22K
        W1           1          Dec 2, 1979   etc   40K
        D5           3          Dec 4, 1979   rrh   15K
        D6           2          Dec 5, 1979   jkf   25K
        D7           5          Dec 6, 1979   jkf   15K
        D8           4          Dec 7, 1979   rrh   19K
        W2           1          Dec 9, 1979   etc   118K
        D9           3         Dec 11, 1979   rrh   15K
       D10           2         Dec 12, 1979   rrh   26K
        D1           5         Dec 15, 1979   rrh   14K
        W3           1         Dec 17, 1979   etc   71K
        D2           3         Dec 18, 1979   etc   13K
      FULL           0         Dec 22, 1979   etc   135K

We do weekly dumps often enough that daily dumps always  fit
on one tape.

     Dumping of files by name is best done by tar(1) but the
amount of data that can be moved in this way is limited to a
single tape.  Finally if  there  are  enough  drives  entire
disks  can  be copied with dd(1) using the raw special files
and an appropriate blocking factor; the  number  of  sectors
per   track   is  usually  a  good  value  to  use,  consult
/etc/disktab.

     It is desirable that full dumps of the root file system
be  made  regularly.   This is especially true when only one
disk is available.  Then, if the root file system is damaged
by  a  hardware or software failure, you can rebuild a work-
able disk doing a restore in the same way that  the  initial
root file system was created.

     Exhaustion of user-file space is certain to  occur  now
and  then;  disk  quotas  may be imposed, or if you prefer a
less fascist approach, try using the programs du(1),  df(1),



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX75


and  quot(8), combined with threatening messages of the day,
and personal letters.

6.4.  Moving file system data

     If you have the resources, the best way to move a  file
system  is to dump it to a spare disk partition, or magtape,
using dump(8), use newfs(8) to create the new  file  system,
and  restore  the file system using restore(8).  Filesystems
may also be moved by piping the output of dump  to  restore.
The  restore  program  uses  an  ``in-place'' algorithm that
allows file system dumps to be restored without concern  for
the  original size of the file system.  Further, portions of
a file system may be selectively  restored  using  a  method
similar to the tape archive program.

     If you have to merge a file system into another, exist-
ing  one, the best bet is to use tar(1).  If you must shrink
a file system, the best bet is  to  dump  the  original  and
restore  it  onto  the  new file system.  If you are playing
with the root file system and only have one drive, the  pro-
cedure is more complicated.  If the only drive is a Winches-
ter disk, this procedure may not be used without overwriting
the  existing root or another partition.  What you do is the
following:

1.   GET A SECOND PACK, OR USE ANOTHER DISK DRIVE!!!!

2.   Dump the root file system to tape using dump(8).

3.   Bring the system down.

4.   Mount the new pack in the correct disk drive, if  using
     removable media.

5.   Load the distribution tape and  install  the  new  root
     file  system  as you did when first installing the sys-
     tem.  Boot normally using the newly created  disk  file
     system.

     Note that if you change the disk  partition  tables  or
add  new disk drivers they should also be added to the stan-
dalone system in /sys/vaxstand, and the default disk  parti-
tion tables in /etc/disktab should be modified.

6.5.  Monitoring System Performance

     The systat program provided with the system is designed
to be an aid to monitoring systemwide activity.  The default
``pigs'' mode shows a dynamic ``ps''.   By  running  in  the
``vmstat''  mode when the system is active you can judge the
system activity in  several  dimensions:  job  distribution,
virtual  memory  load,  paging and swapping activity, device
interrupts, and disk and cpu  utilization.   Ideally,  there



                      December 6, 2003





SMM:1-76ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


should  be few blocked (b) jobs, there should be little pag-
ing  or  swapping  activity,  there  should   be   available
bandwidth  on the disk devices (most single arms peak out at
20-30 tps in practice), and the user  cpu  utilization  (us)
should be high (above 50%).

     If the system is busy, then the count  of  active  jobs
may be large, and several of these jobs may often be blocked
(b).  If the virtual memory is active, then the paging demon
will  be  running  (sr will be non-zero).  It is healthy for
the paging demon to free pages when the virtual memory  gets
active;  it  is triggered by the amount of free memory drop-
ping below a threshold and increases its pace as free memory
goes to zero.

     If you run in the ``vmstat'' mode when  the  system  is
busy, you can find imbalances by noting abnormal job distri-
butions.  If many processes are blocked (b), then  the  disk
subsystem  is overloaded or imbalanced.  If you have several
non-dma devices or open teletype lines that are ``ringing'',
or  user  programs  that  are  doing high-speed non-buffered
input/output, then the system time may go  high  (60-70%  or
higher).  It is often possible to pin down the cause of high
system time by looking to see if there is excessive  context
switching  (cs),  interrupt  activity  (in)  and  per-device
interrupt counts, or system  call  activity  (sy).   Cumula-
tively  on one of our large machines we average about 60-100
context switches and interrupts per second and about  70-120
system calls per second.

     If the system is heavily loaded, or if you have  little
memory  for  your load (2M is little in most any case), then
the system may be forced to swap.   This  is  likely  to  be
accompanied  by a noticeable reduction in system performance
and pregnant pauses when interactive jobs  such  as  editors
swap  out.  If you expect to be in a memory-poor environment
for an extended period you might  consider  administratively
limiting system load.

6.6.  Recompiling and reinstalling system software

     It is easy to regenerate the system, and it is  a  good
idea  to try rebuilding pieces of the system to build confi-
dence in the procedures.  The system consists of  two  major
parts:  the  kernel  itself  (/sys)  and  the  user programs
(/usr/src and subdirectories).  The major part  of  this  is
/usr/src.

     The  three  major  libraries  are  the  C  library   in
/usr/src/lib/libc      and     the     FORTRAN     libraries
/usr/src/usr.lib/libI77  and  /usr/src/usr.lib/libF77.    In
each  case  the  library  is  remade  by  changing  into the
corresponding directory and doing




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX77



        # make

and then installed by

        # make install

Similar to the system,

        # make clean

cleans up.

     The source for all other libraries is kept in subdirec-
tories  of  /usr/src/usr.lib; each has a makefile and can be
recompiled by the above recipe.

     If you look at /usr/src/Makefile, you will see that you
can recompile the entire system source with one command.  To
recompile a specific program,  find  out  where  the  source
resides  with  the  whereis(1)  command, then change to that
directory and remake it with the  Makefile  present  in  the
directory.  For instance, to recompile ``date'', all one has
to do is

        # whereis date
        date: /usr/src/bin/date.c /bin/date
        # cd /usr/src/bin
        # make date

this will create an unstripped  version  of  the  binary  of
``date''  in  the  current directory.  To install the binary
image, use the install command as in

        # install -s date -o bin -g bin -m 755 /bin/date

The -s option will insure the installed version of date  has
its  symbol  table  stripped.  The install command should be
used instead of mv or cp as it understands  how  to  install
programs even when the program is currently in use.

     If you wish to recompile and install all programs in  a
particular  target  area you can override the default target
by doing:

        # make
        # make DESTDIR=pathname install


     To regenerate all the system source you can do

        # cd /usr/src
        # make clean; make depend; make




                      December 6, 2003





SMM:1-78ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


     If you modify the C library, say  to  change  a  system
call,  and  want  to  rebuild  and  install  everything from
scratch you have to be a little careful.   You  must  insure
that the libraries are installed before the remainder of the
source, otherwise the loaded images will not contain the new
routine  from  the  library.   The  following  sequence will
accomplish this.

        # cd /usr/src
        # make clean
        # make depend
        # make build
        # make installsrc

The make clean removes any existing binary or  object  files
in the source trees to insure that everything will be recom-
piled and reloaded.  The make depend recreates  all  of  the
dependencies.   See  mkdep(1)  for further details. The make
build compiles and installs  the  libraries  and  compilers,
then   recompiles   the  libraries  and  compilers  and  the
remainder of the sources.  The make installsrc installs  all
of  the  commands  not  installed as part of the make build.
This will take approximately 4 hours on a KA655.

6.7.  Making local modifications

     Locally written commands that  aren't  distributed  are
kept  in  /usr/src/local  and  their  binaries  are  kept in
/usr/local.  This allows /usr/bin,  /usr/ucb,  and  /bin  to
correspond to the distribution tape (and to the manuals that
people can buy).  People using local commands should be made
aware that they aren't in the base manual.  Manual pages for
local commands should be installed in /usr/src/local/man and
installed  in  /usr/local/man/cat[1-8].   The man(1) command
automatically    finds    manual     pages     placed     in
/usr/local/man/cat[1-8] to facilitate this practice.

6.8.  Accounting

     UNIX optionally records two kinds of accounting  infor-
mation:   connect   time  accounting  and  process  resource
accounting.  The  connect  time  accounting  information  is
stored in the file /usr/adm/wtmp, which is summarized by the
program ac(8).  The process time accounting  information  is
stored in the file /usr/adm/acct after it is enabled by acc-
ton(8), and is analyzed and summarized by the program sa(8).

     If you need to recharge for  computing  time,  you  can
develop  procedures  based  on  the  information provided by
these commands.  A convenient way to do this is to give com-
mands to the clock daemon /etc/cron to be executed every day
at a specified time.   This  is  done  by  adding  lines  to
/usr/adm/crontab; see cron(8) for details.




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX79


6.9.  Resource control

     Resource control in the current version of UNIX is more
elaborate than in most UNIX systems.  The disk quota facili-
ties developed at the  University  of  Melbourne  have  been
incorporated in the system and allow control over the number
of files and amount of disk space each user may use on  each
file  system.   In  addition,  the resources consumed by any
single  process  can  be  limited  by  the   mechanisms   of
setrlimit(2).   As  distributed,  the  latter  mechanism  is
voluntary, though sites  may  choose  to  modify  the  login
mechanism to impose limits not covered with disk quotas.

     To use the disk quota facilities, the  system  must  be
configured with ``options QUOTA''.  File systems may then be
placed under the quota mechanism by  creating  a  null  file
quotas  at  the  root  of  the  file  system, running quota-
check(8), and modifying /etc/fstab to  show  that  the  file
system  is  read-write  with  disk  quotas  (an  ``rq'' type
field).  The quotaon(8) program may then be  run  to  enable
quotas.

     Individual quotas are applied by using the quota editor
edquota(8).   Users  may view their quotas (but not those of
other users) with the  quota(1)  program.   The  repquota(8)
program  may  be  used  to  summarize the quotas and current
space usage on a particular file system or file systems.

     Quotas are enforced with soft and hard limits.  When  a
user  first reaches a soft limit on a resource, a message is
generated on his/her terminal.  If the user fails  to  lower
the  resource  usage below the soft limit the next time they
log in to the system the login program will generate a warn-
ing  about  excessive usage.  Should three login sessions go
by with the soft limit breached the system then  treats  the
soft  limit  as  a  hard limit and disallows any allocations
until enough space is reclaimed to bring the user back below
the soft limit.  Hard limits are enforced strictly resulting
in errors when a user tries to create or write a file.  Each
time  a  hard  limit  is exceeded the system will generate a
message on the user's terminal.

     Consult the auxiliary document, ``Disc Quotas in a UNIX
Environment''  and  the  appropriate manual entries for more
information.

6.10.  Network troubleshooting

     If you have anything more than a trivial network confi-
guration,  from time to time you are bound to run into prob-
lems.  Before blaming the software, first check your network
connections.  On networks such as the Ethernet a loose cable
tap  or  misplaced  power  cable  can  result  in   severely
deteriorated  service.  The netstat(1) program may be of aid



                      December 6, 2003





SMM:1-80ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


in tracking down hardware malfunctions.  In particular, look
at the -i and -s options in the manual page.

     Should you believe  a  communication  protocol  problem
exists,  consult  the protocol specifications and attempt to
isolate the problem in a packet trace.  The SO DEBUG  option
may  be  supplied  before  establishing  a  connection  on a
socket, in which case the system will trace all traffic  and
internal  actions  (such  as  timers expiring) in a circular
trace buffer.  This buffer may then be printed out with  the
trpt(8C)  program.  Most of the servers distributed with the
system accept a -d option forcing all sockets to be  created
with  debugging  turned  on.  Consult the appropriate manual
pages for more information.

6.11.  Files that need periodic attention

     We conclude the  discussion  of  system  operations  by
listing  the  files  that  require periodic attention or are
system specific:

/etc/fstab           how disk partitions are used
/etc/disktab         default disk partition sizes/labels
/etc/printcap        printer data base
/etc/gettytab        terminal type definitions
/etc/remote          names and phone numbers of remote machines for tip(1)
/etc/group           group memberships
/etc/motd            message of the day
/etc/passwd          password file; each account has a line
/etc/rc.local        local system restart script; runs reboot; starts daemons
/etc/inetd.conf      local internet servers
/etc/hosts           host name data base
/etc/networks        network name data base
/etc/services        network services data base
/etc/hosts.equiv     hosts under same administrative control
/etc/syslog.conf     error log configuration for syslogd(8)
/etc/ttys            enables/disables ports
/usr/lib/crontab     commands that are run periodically
/usr/lib/aliases     mail forwarding and distribution groups
/usr/adm/acct        raw process account data
/usr/adm/messages    system error log
/usr/adm/wtmp        login session accounting















                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX81


               APPENDIX A - BOOTSTRAP DETAILS



     This appendix  contains  pertinent  files  and  numbers
regarding the bootstrapping procedure for 4.3BSD-Quasijarus.
You should never have to look at this appendix.  However, if
there  are  problems  in installing the distribution on your
machine, the material contained here may prove useful.

Contents of the distribution tape(s)

     The distribution normally consists of two 1600bpi 2400'
magnetic tapes, one 6250bpi 2400' magnetic tape, or one TK50
tape cartridge.  The layout of the 6250bpi  tape  is  listed
below.   The TK50 tape and the 1600bpi tapes are in the same
order, but the tar(1) images of source code  are  compressed
with  compress(1).  In the 1600bpi distribution the binaries
(first four tape files)  are  on  the  first  tape  and  the
compressed  sources  (last two tape files) are on the second
tape.  All tape files are blocked in 10  kilobytes  records,
except  for  the  first  file on the first tape that has 512
byte records.


Tape file   Records*   Contents

one         210        6 bootstrap monitor programs and a
                       tp(1) file containing boot, format, and copy
two         308        ``mini root'' file system
three       430        dump(8) of distribution root file system
four        3000       tar(1) image of binaries and libraries in /usr
five        720        tar(1) image of /sys, including GENERIC system
six         2500       tar(1) image of /usr/src



     The distribution tape is made with  the  shell  scripts
located in the directory /sys/vaxdist.  To build a distribu-
tion tape one must first create a mini root file system with
the buildmini shell script.










* The number of records in each tape file are  approxi-
mate and do not correspond to the actual tape.




                      December 6, 2003





SMM:1-82ling and Operating 4.3BSD-Quasijarus UNIX on the VAX



        #!/bin/sh -
        #
        # 4.3BSD-Quasijarus release-making script.
        #
        # This file is freely redistributable.
        #
        #       @(#)buildmini   4.10 (Berkeley) 10/3/99
        #

        dist=/sys/vaxdist
        miniroot=ra0d
        minimnt=/tmp/mini

        date
        mkdir ${minimnt}
        newfs -s 6144 ${miniroot}
        fsck /dev/r${miniroot}
        mount /dev/${miniroot} ${minimnt}
        cd ${minimnt}; sh ${dist}/get
        cd /; sync
        umount /dev/${miniroot}
        fsck /dev/r${miniroot}
        date

The buildmini script uses the get script to build  the  file
system.

        #!/bin/sh -
        #
        # 4.3BSD-Quasijarus release-making script.
        #
        # This file is freely redistributable.
        #
        #       @(#)get 4.28 (Berkeley) 9/7/99
        #

        # Shell script to build a mini-root file system in preparation for building
        # a distribution tape.  The file system created here is image copied onto
        # tape, then image copied onto disk as the "first" step in a cold boot of
        # 4.3 systems.

        if [ `pwd` = '/' ]
        then
                echo You just '(almost)' destroyed the root
                exit
        fi
        cp /nbsd/sys/GENERIC/vmunix vmunix

        # create necessary directories
        DIRLIST="bin dev etc a tmp usr usr/mdec sys sys/floppy  sys/cassette sys/consolerl"
        rm -rf $DIRLIST
        mkdir $DIRLIST




                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX83


        ETC="disktab disklabel diskpart fsck ifconfig init mknod mount newfs restore    rrestore umount arff flcopy passwd group"
        for i in $ETC; do
                cp /nbsd/etc/$i etc/$i
        done

        BIN="[ cat cp dd echo expr ls mkdir mv rcp rm sh stty sync ed awk make mt"
        for i in $BIN; do
                cp /nbsd/bin/$i bin/$i
        done
        ln bin/stty bin/STTY

        cp /nbsd/sys/floppy/[Ma-z0-9]* sys/floppy
        cp /nbsd/sys/consolerl/[Ma-z0-9]* sys/consolerl
        cp /nbsd/sys/cassette/[Ma-z0-9]* sys/cassette
        cp /nbsd/usr/mdec/* usr/mdec
        cp /nbsd/boot boot
        cp /nbsd/pcs750.bin pcs750.bin
        cp /nbsd/.profile .profile

        cat >etc/fstab <<EOF
        /dev/hp0a:/a:xx:1:1
        /dev/up0a:/a:xx:1:1
        /dev/hk0a:/a:xx:1:1
        /dev/ra0a:/a:xx:1:1
        /dev/kra0a:/a:xx:1:1
        /dev/rb0a:/a:xx:1:1
        EOF

        cat >xtr <<'EOF'
        : ${disk?'Usage: disk=xx0 tape=yy xtr'}
        : ${tape?'Usage: disk=xx0 tape=yy xtr'}
        echo 'Build root file system'
        newfs ${disk}a
        sync
        echo 'Check the file system'
        fsck /dev/r${disk}a
        mount /dev/${disk}a /a
        cd /a
        echo 'Rewind tape'
        mt -f /dev/${tape}0 rew
        echo 'Restore the dump image of the root'
        restore rsf 3 /dev/${tape}0
        cd /
        sync
        umount /dev/${disk}a
        sync
        fsck /dev/r${disk}a
        echo 'Root filesystem extracted'
        echo
        echo 'If this is an 8650 or 8600, update the console rl02'
        echo 'If this is a 780 or 785, update the floppy'
        echo 'If this is a 730, update the cassette'
        EOF
        chmod +x xtr



                      December 6, 2003





SMM:1-84ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


        rm -rf dev; mkdir dev
        cp /nbsd/dev/MAKEDEV dev
        chmod +x dev/MAKEDEV
        cp /dev/null dev/MAKEDEV.local
        cd dev
        ./MAKEDEV std hp0 hk0 up0 ra0 kra0 rb0
        ./MAKEDEV ts0; mv rmt12 ts0; rm *mt*;
        ./MAKEDEV tm0; mv rmt12 tm0; rm *mt*;
        ./MAKEDEV ht0; mv rmt12 ht0; rm *mt*;
        ./MAKEDEV ut0; mv rmt12 ut0; rm *mt*;
        ./MAKEDEV tms0; mv rmt12 tms0; rm *mt*;
        ./MAKEDEV mt0; mv rmt12 xt0; rm *mt*; mv xt0 mt0
        cd ..
        sync

The mini root file system must have enough space to hold the
files found on a floppy or cassette.

     Once a mini root file system is constructed,  the  mak-
etape script makes a distribution tape.

        #!/bin/sh -
        #
        # 4.3BSD-Quasijarus release-making script.
        #
        # This file is freely redistributable.
        #
        #       @(#)maketape    4.36 (Berkeley) 12/6/03
        #

        # maketape releasedir
        miniroot=ra0d
        fullroot=ra1a
        block=20
        tflag=cbf

        if [ $# -gt 0 ]; then
                releasedir=$1;
        else
                echo usage: $0 releasedir
                exit
        fi

        cd /nbsd
        sync

        cd /nbsd/sys/vaxdist/tp
        tp cmf /tmp/tape.$$ boot copy format
        cd /nbsd/sys/mdec
        echo "Build 1st level boot block file"
        cat tmscpboot tsboot htboot tmboot mtboot utboot /tmp/tape.$$ |         dd of=${releasedir}/stand obs=512 conv=sync

        echo "Add image of mini-root file system"
        dd if=/dev/r${miniroot} count=308 bs=20b conv=sync of=${releasedir}/miniroot



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX85


        echo "Add full dump of real file system"
        /etc/dump 0f ${releasedir}/rootdump /dev/r${fullroot}

        echo "Add tar image of /usr"
        cd /nbsd/usr
        tar ${tflag} ${block} ${releasedir}/usr.tar MAKEHOSTS adm bin dict games hosts  include lib local man mdec msgs new old pres

        echo "Add tar image of system sources"
        cd /nbsd/usr/src/sys
        tar ${tflag} ${block} ${releasedir}/srcsys.tar .

        echo "Add user source code"
        FILES="Makefile bin cci doc etc games include lib local man old         ucb undoc usr.bin usr.lib"
        cd /nbsd/usr/src
        tar ${tflag} ${block} ${releasedir}/src.tar ${FILES}


     Summarizing then, to create a distribution tape you can
use the above scripts and the following commands.

        # buildmini
        # maketape /distdir

This will generate the  distribution  tape  file  images  in
/distdir.

Control status register addresses

     The distribution uses many  standalone  device  drivers
that  presume  the  location  of  a  UNIBUS device's control
status register (CSR).  The following table summarizes these
values.


        Device name   Controller      CSR address (octal)
        

        ra            DEC UDA50       0172150
        rb            DEC 730 IDC     0175606
        rk            DEC RK11        0177440
        rl            DEC RL11        0174400
        tm            EMULEX TC-11    0172520
        ts            DEC TS11        0172520
        up            EMULEX SC-21V   0176700
        ut            SI 9700         0172440


All MASSBUS controllers are located at standard offsets from
the  base  address of the MASSBUS adapter register bank.  BI
bus controllers are located automatically.

Generic system control status register addresses

     The generic version of the  operating  system  supplied
with  the  distribution  contains  the UNIBUS devices listed



                      December 6, 2003





SMM:1-86ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


below. These devices will be recognized if  the  appropriate
control status registers respond at any of the listed UNIBUS
addresses.


        Device name   Controller           CSR addresses (octal)
        

        hk            DEC RK11             0177440
        tm            EMULEX TC-11         0172520
        tmscp         DEC TU81, TMSCP      0174500
        ts            DEC TS11             0172520
        ut            SI 9700              0172440
        up            EMULEX SC-21V        0176700, 0174400, 0176300
        ra            DEC UDA-50           0172150, 0172550, 0177550
        rb            DEC 730 IDC          0175606
        rl            DEC RL11             0174400
        dm            DM11 equivalent      0170500
        dh            DH11 equivalent      0160020, 0160040
        dhu           DEC DHU11            0160440, 0160500
        dz            DEC DZ11             0160100, 0160110, ... 0160170
        dmf           DEC DMF32            0160340
        dmz           DEC DMZ32            0160540
        lp            DEC LP11             0177514
        en            Xerox 3MB ethernet   0161000
        ec            3Com ethernet        0164330
        ex            Excelan ethernet     0164344
        il            Interlan ethernet    0164000
        de            DEC DEUNA            0174510


If devices other than the above are located at  any  of  the
addresses listed, the system may not bootstrap properly.

























                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX87


           APPENDIX B - LOADING THE TAPE MONITOR



     This  section  describes  how  the  bootstrap   monitor
located  on  the first tape of the distribution tape set may
be loaded.  This should not be necessary  if  using  console
media,  but has been included as a fallback measure if it is
not possible to read the distributed console  medium.   This
procedure must be used however on MicroVAXen as they have no
console media.  WARNING:  the bootstraps supplied below  may
not work, in certain instances on an 11/730 because they use
a buffered data path for  transferring  data  from  tape  to
memory; consult our group if you are unable to load the mon-
itor on an 11/730.  All of the addresses given  below  refer
to the first SBIA on the 8600.

     To load the tape bootstrap  monitor,  first  mount  the
magnetic tape on drive 0 at load point, making sure that the
write ring is not inserted.  The  following  description  of
toggle-in  code  applies  only to large VAXen with non-TMSCP
tapes.  On MicroVAXen all you need to do is to boot from the
distribution tape:

        >>>B MUA0

and the ``='' prompt will appear.  On  large  VAXen  a  more
complex  procedure  described  below  must  be used instead.
Once again, it works only for non-TMSCP tapes.  To bootstrap
4.3BSD-Quasijarus on a large VAX from a TMSCP tape drive you
must use console media.  This procedure can be  used  on  an
8200,  however,  since  8200s normally use TMSCP tapes it is
unlikely to be very  useful.   Temporarily  set  the  reboot
switch  on  an 11/780 or 11/730 to off; on an 8600 or 11/750
set the power-on action to halt.  (In  normal  operation  an
11/785,  11/780,  or  11/730 will have the reboot switch on,
and an 8600 or 11/750 will have the power-on action  set  to
boot/restart.)

     If you have an 8600 or 11/780 give the commands:

        >>>HALT
        >>>UNJAM

Then, on any machine, give the init command:

        >>>I

and then key in at location 200 and execute either  the  TS,
HT, TM, or MT bootstrap that follows, as appropriate.  NOTE:
All of the addresses given in  this  section  refer  to  the
first SBIA on the 8600.  Also, the VAX 8200 console does not
accept the ``D +'' command, so the  second  command  becomes
``D 204 D05A0000'', the third ``D 208 3BEF'', the fourth ``D



                      December 6, 2003





SMM:1-88ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


20C 800CA00'', the fifth ``D 210  32EFC1'',  and  so  forth.
Alternatively, you could try booting BOOT58 via ``B/R5:800''
with a diagnostic floppy.

     The machine's printouts are shown in boldface, explana-
tory comments are within ( ).  You can use `delete' to erase
a character and `control U' to kill the whole line.


        TS bootstrap

        >>>D/P 200 3AEFD0
        >>>D + D05A0000
        >>>D + 3BEF
        >>>D + 800CA00
        >>>D + 32EFC1
        >>>D + CA010000
        >>>D + EFC10804
        >>>D + 24
        >>>D + 15508F
        >>>D + ABB45B00
        >>>D + 2AB9502
        >>>D + 8FB0FB18
        >>>D + 956B024C
        >>>D + FB1802AB
        >>>D + 25C8FB0
        >>>D + 6B
                (The next two deposits set up the addresses of the UNIBUS)
                (adapter and its memory; the 20006000 here is the address of)
                (uba0 and the 2013E000 the address of the I/O page, umem0)
                (on an 8600 or 11/780)
        >>>D + 20006000         (8600/780 uba0)
                (8600/780 uba1: 20008000, uba2 2000A000)
                (8200 uba at node 0: 20000000)
                (750 uba0: F30000, uba1: F32000; 730 uba: F26000)
        >>>D + 2013E000         (8600/780 umem0)
                (8600/780 umem1: 2017E000, umem2: 201BE000)
                (8200 umem at node 0: 20400000)
                (750 umem0: FFE000, umem1: FBE000; 730 umem: FFE000)
        >>>D + 80000000
        >>>D + 254C004
        >>>D + 80000
        >>>D + 264
        >>>D + E
        >>>D + C001
        >>>D + 2000000
        >>>S 200
        >>>S 200
        >>>S 200

                N.B.: uba and umem addresses can be determined algorithmically
                on 8200 machines as follows:
                        uba(node) = 20000000 + (2000 * node)
                        umem(node) = 20400000 + (40000 * node)



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX89


        HT bootstrap

        >>>D/P 200 3EEFD0
        >>>D + C55A0000
        >>>D + 3BEF
        >>>D + 808F00
        >>>D + C15B0000
        >>>D + C05B5A5B
        >>>D + 4008F
        >>>D + D05B00
        >>>D + 9D004AA
        >>>D + C08F326B
        >>>D + D424AB14
        >>>D + 8FD00CAA
        >>>D + 80000000
        >>>D + 320800CA
        >>>D + AAFE008F
        >>>D + 6B39D010
        >>>D + 0
                (The next two deposits set up the addresses of the MASSBUS)
                (adapter and the drive number for the tape formatter)
                (the 20010000 here is the address of mba0 on an 8600 or)
                (11/780 and the 0 indicates the formatter is drive 0 on mba0)
        >>>D + 20010000         (8600/780 mba0)
                (8600/780 mba1: 20012000; 750 mba0: F28000, mba1: F2A000)
        >>>D + 0                                (Formatter unit number in range 0-7)
        >>>S 200
        >>>S 200
        >>>S 200
        >>>S 200

        TM bootstrap

        >>>D/P 200 2AEFD0
        >>>D + D0510000
        >>>D + 2000008F
        >>>D + 800C180
        >>>D + 804C1D4
        >>>D + 1AEFD0
        >>>D + C8520000
        >>>D + F5508F
        >>>D + 8FAE5200
        >>>D + 4A20200
        >>>D + B006A2B4
        >>>D + 2A203
                (The following two numbers are uba0 and umem0 on a 8600/780)
                (See TS above for values for other CPU's and UBA's)
        >>>D + 20006000         (8600/780 uba0)
        >>>D + 2013E000         (8600/780 umem0)
        >>>S 200
        >>>S 200
        >>>S 200
        >>>S 200
        >>>S 200



                      December 6, 2003





SMM:1-90ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


        MT bootstrap

        >>>D/P 200 46EFD0
        >>>D + C55A0000
        >>>D + 43EF
        >>>D + 808F00
        >>>D + C15B0000
        >>>D + C05B5A5B
        >>>D + 4008F
        >>>D + 19A5B00
        >>>D + 49A04AA
        >>>D + AAD408AB
        >>>D + 8FD00C
        >>>D + CA800000
        >>>D + 8F320800
        >>>D + 10AAFE00
        >>>D + 2008F3C
        >>>D + ABD014AB
        >>>D + FE15044
        >>>D + 399AF850
        >>>D + 6B
                (The next two deposits set up the addresses of the MASSBUS)
                (adapter and the drive number for the tape formatter)
                (the 20012000 here is the address of mba1 on an 8600 or)
                (11/780 and the 0 indicates the formatter is drive 0 on mba1)
        >>>D + 20012000
        >>>D + 0
        >>>S 200
        >>>S 200
        >>>S 200
        >>>S 200
        >>>S 200
        >>>S 200

        (no functioning toggle-in code  exists  for  the  UT
        device)


     If the tape doesn't move the first time you  start  the
bootstrap  program  with ``S 200'' you probably have entered
the program incorrectly (but also check  that  the  tape  is
online).  Start over and check your typing.  For the HT, MT,
and TM bootstraps you will not  be  able  to  see  the  tape
motion  as  you  advance through the first few blocks as the
tape motion is all within the vacuum columns.

     Next, deposit in R10 the address of  the  tape  MBA/UBA
and  in  R11  the  address  of  the device registers or unit
number from one of:








                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX91




        >>>D/G A 20006000   (for tapes on 8600/780 uba0)
        >>>D/G A 20008000   (for tapes on 8600/780 uba1)
        >>>D/G A 20010000   (for tapes on 8600/780 mba0)
        >>>D/G A 20012000   (for tapes on 8600/780 mba1)
        >>>D/G A 20000000   (for tapes on 8200 uba at node 0)
        >>>D/G A F30000     (for tapes on 750 uba0)
        >>>D/G A F32000     (for tapes on 750 uba1)
        >>>D/G A F28000     (for tapes on 750 mba0)
        >>>D/G A F2A000     (for tapes on 750 mba1)
        >>>D/G A F26000     (for tapes on 730 uba0)


and for register 11:


        >>>D/G B 0          (for TM03/TM78 formatters at mba? drive 0)
        >>>D/G B 1          (for TM03/TM78 formatters at mba? drive 1)
        >>>D/G B 2013F550   (for TM11/TS11/TU80 tapes on 8600/780 uba0)
        >>>D/G A 20400000   (for TM11/TS11/TU80 on 8200 uba at node 0)
        >>>D/G B FFF550     (for TM11/TS11/TU80 tapes on 750 or 730 uba0)


Then start the bootstrap program with

        >>>S 0


     The console should type

        =

You are now talking to the tape bootstrap monitor.   At  any
point in the following procedure you can return to this sec-
tion, reload the tape bootstrap, and restart the  procedure.
The  console monitor is identical to that loaded from a TU58
console cassette, follow the instructions in  section  2  as
they  apply to this device.  The only exception is that when
using programs loaded from the tape bootstrap monitor,  pro-
grams  will always return to the monitor (the ``='' prompt).
This saves your having to type in the above  toggle-in  code
for each program to be loaded.














                      December 6, 2003





SMM:1-92ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


         APPENDIX C - INSTALLATION TROUBLESHOOTING



     This appendix lists and explains certain problems  that
might  be  encountered  while  trying to install the 4.3BSD-
Quasijarus distribution.  The information provided  here  is
limited to the early steps in the installation process; i.e.
up to the point where the root file system is installed.  If
you  have a problem installing the release consult this sec-
tion before contacting our group.

Using the distribution console medium.

This section describes problems that may  occur  when  using
the  programs  provided  on  the distributed console medium:
TU58 cassette or RX01 floppy disk.

program can not be loaded.

Check to make sure the correct floppy or cassette  is  being
used.   If using a floppy, be sure it is not in upside down.
If using a cassette on an 11/730,  be  certain  drive  0  is
being  used.   If  a hard I/O error occurred while reading a
floppy, try resetting the console LSI-11 by powering  it  on
and off.  If you can not boot the cassette's bootstrap moni-
tor, verify that the standard DEC console  cassette  can  be
read; if it can not, your cassette drive is probably broken.

program halts without warning.

Check to make sure you have specified the  correct  disk  to
format; consult sections 1.3 and 1.4 for a discussion of the
VAX and UNIX device naming conventions.  On 11/750's, speci-
fying  a  non-existent MASSBUS device will cause the program
to halt as it receives  an  interrupt  (standalone  programs
operate by polling devices).

If using a floppy, try reading the floppy under your current
system.   If  this  works,  copy the floppy to a new one and
begin again.  If using a cassette on an 11/730, do likewise.

format prints ``Known devices are ...''.

You have requested format to work on a device for  which  it
has  no driver, or that does not exist; only the listed dev-
ices are supported.

format, boot, or copy prints ``unknown drive type''.

A MASSBUS disk was specified,  but  the  associated  MASSBUS
drive type register indicates a drive of unknown type.  This
probably means you typed something wrong or your hardware is
incorrectly configured.



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX93


format, boot, or copy prints ``unknown device''.

The device specified is probably not one of those  supported
by  the distribution; consult section 1.1.  If the device is
listed in section 1.1, the drive may be dual-ported, or  for
some  other  reason  the  driver  was unable to decipher its
characteristics.  If this is a MASSBUS drive,  try  powering
the  MASSBUS  adapter  and/or controller on and off to clear
the drive type register.

copy does not copy 308 records

If a tape read error occurred, clean your tape drive  heads.
If a disk write error occurred, the disk formatting may have
failed.  If the disk pack is removable, try another one.  If
you are currently running UNIX, you can reboot your old sys-
tem and use dd to copy the mini-root file system into a disk
partition  (assuming  the  destination  is not in use by the
running system).

boot prints ``not a directory''

The boot program was unable to find  the  requested  program
because  it  encountered  something  other  than a directory
while searching the file system.  This usually suggests that
no file system is present on the disk partition supplied, or
the file system has been corrupted.   First  check  to  make
sure  you  typed  the  correct line to boot.  If this is the
case and you are booting from the mini-root file system, the
mini-root  was  probably  not  copied correctly off the tape
(perhaps it was not placed in the correct  disk  partition).
Try  reinstalling the mini-root file system or, if trying to
boot the true root file system, try booting from  the  mini-
root file system and run fsck on the restored root file sys-
tem to insure its integrity.  Finally,  as  a  last  resort,
copy  the boot program from the mini-root file system to the
newly installed root file system.

boot prints ``bad format''

The program you requested boot to load did not have  a  407,
410,  or  413 magic number in its header.  This should never
happen on a distribution system.  If you were trying to boot
off the root file system, reboot the system on the mini-root
file system and look at the program on the root file system.
Try  copying the copy of vmunix on the mini-root to the root
file system also.

boot prints ``Short read''

The file header for the program contained a size larger than
the  actual size of the file located on disk.  This is prob-
ably the result of file system corruption  (or  a  disk  I/O
error).   Try  booting  again  or creating a new copy of the



                      December 6, 2003





SMM:1-94ling and Operating 4.3BSD-Quasijarus UNIX on the VAX


program to be loaded (see above).

Booting the generic system

This section contains common problems encountered when boot-
ing the generic version of the system.

system panics with ``panic: iinit''

This occurred because the system was  unable  to  mount  the
root  file  system.   The  root  file system supplied at the
``root device?'' prompt was  probably  incorrect.   Remember
that  when  running on the mini-root file system, this ques-
tion must be answered with something of the  form  ``hp0*''.
If  the  answer had been ``hp0'', the system would have used
the ``a'' partition on unit 0 of  the  ``hp''  drive,  where
presumably no file system exists.

Alternatively, the file system on which you were  trying  to
run  is  corrupted.   Try  reinstalling the appropriate file
system.

system selects incorrect root device

That is, you try to boot the system single user with ``B/2''
or  ``B  xxS''  but  do  not get the root file system in the
expected location.  This is most likely caused by your  hav-
ing  many disks available more suited to be a root file sys-
tem than the one you wanted.  For example,  if  you  have  a
``up'' disk and an ``hk'' disk and install the system on the
``hk'', then try to boot the system to single-user mode, the
heuristic used by the generic system to select the root file
system will choose the  ``up''  disk.   The  following  list
gives,  in  descending order, those disks thought most suit-
able to be a  root  file  system:  ``hp'',  ``up'',  ``ra'',
``rb'', ``rl'', ``hk'' (the position of ``rl'' is subject to
argument). To get the root device you  want  you  must  boot
using  ``B/3''  or ``B ANY'', then supply the root device at
the prompt.

system crashes during autoconfiguration

This is almost always caused by an unsupported UNIBUS device
being  present  at  a  location where a supported device was
expected.  You must disable the device in some  way,  either
by  pulling it off the bus, or by moving the location of the
console status register (consult Appendix A for  a  complete
list of UNIBUS csr's used in the generic system).

system does not find device(s)

The UNIBUS device is not at a  standard  location.   Consult
the list of control status register addresses in Appendix A,
or wait to configure a system to your hardware.



                      December 6, 2003





Installing and Operating 4.3BSD-Quasijarus UNIX on theMVAX95


Alternatively, certain devices are difficult to locate  dur-
ing  autoconfiguration.   A classic example is the TS11 tape
drive that does not autoconfigure properly if it is  rewind-
ing when the system is rebooted.  Tape drives should config-
ure properly if they are off-line, or are not  performing  a
tape  movement.   Disks that are dual-ported should autocon-
figure properly if the drive  is  not  being  simultaneously
accessed through the alternate port.

Building console cassettes

This sections describes common  problems  encountered  while
constructing a console bootstrap cassette.

system crashes

You are trying to build a cassette for  an  11/750.   On  an
11/750  the  system  is booted by using a bootstrap prom and
sector 0 of the root file system.  Refer to section 2.2.5 or
tu(4) for the appropriate reprimand.

system hangs

You are using an MRSP prom on an 11/750 and  think  you  can
ignore  the instructions in this document.  The problem here
is that the generic system only supports the MRSP prom on an
11/730.   Using  it  on  an 11/750 requires a special system
configuration; consult tu(4) for more information.





























                      December 6, 2003