BSD 4_4 release

[unix-history] / usr / src / share / doc / smm / 01.setup / 1.t

diff --git a/usr/src/share/doc/smm/01.setup/1.t b/usr/src/share/doc/smm/01.setup/1.t
index 7f2c798..2f71b77 100644 (file)
--- a/usr/src/share/doc/smm/01.setup/1.t
+++ b/usr/src/share/doc/smm/01.setup/1.t
@@ -1,311 +1,146 @@
-.\" Copyright (c) 1980 Regents of the University of California.
-.\" All rights reserved.  The Berkeley software License Agreement
-.\" specifies the terms and conditions for redistribution.
+.\" Copyright (c) 1988, 1993 The Regents of the University of California.
+.\" All rights reserved.

 .\"
 .\"

-.\"    @(#)1.t 6.1 (Berkeley) 5/14/86
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"    This product includes software developed by the University of
+.\"    California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"    @(#)1.t 8.1 (Berkeley) 7/27/93

 .\"
 .ds lq ``
 .ds rq ''
 .ds LH "Installing/Operating \*(4B
 .ds RH Introduction
 .\"
 .ds lq ``
 .ds rq ''
 .ds LH "Installing/Operating \*(4B
 .ds RH Introduction

-.ds CF \*(DY
+.ds CF \*(Dy

 .LP
 .LP

-.nr H1 1

 .bp
 .bp

-.LG
-.B
-.ce
-1. INTRODUCTION
-.sp 2
-.R
-.NL
-.PP
-This document explains how to install the \*(4B release of the Berkeley
-version of UNIX for the Tahoe on your system.  While this is the first
-release from Berkeley for the Tahoe, the version of
-.UX
-distributed by CCI is derived from 4.2BSD.  Consequently, the filesystem
-format is compatible and it will only be necessary for you to perform
-a full bootstrap procedure if you are installing the release on a new
-machine.
-The System V UNIX systems distributed by CCI, Sperry and Harris
-are also derived from 4.2BSD, but only the network and filesystem
-remain compatible with 4.2 and 4.3.
-The object file formats are completely different in the System V
-releases.
-Thus, the most straightforward procedure for upgrading a System V
-system is to perform a full bootstrap.  The full bootstrap procecure
-is outlined in chapter 2; the process includes booting standalone
-utilities from tape to format a disk, if necessary, and then copying
-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).
-.PP
-The technique for upgrading a 4.2BSD-based system is described
-in chapter 3 of this document.
-As 4.3BSD 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 user filesystems may up upgraded in place.
-Some 4.2BSD binaries may be used with 4.3BSD in the course of the conversion.
-However due to significant incompatibilities between the vendor derived
-version of 4.2BSD and the \*(4B release, most binary images will not function
-properly.  For such programs it will be necessary, as well as desirable,
-to recompile this software after the conversion.  Consult section 3 for
-a description of the differences between \*(4B and the previous systems
-provided for the Tahoe.
-.NH 2
-Hardware supported
-.PP
-This distribution can be booted on a CCI Power 6/32, Harris HCX-7
-or Sperry 7000/40
-with any disks supported on the VERSABUS disk controllers
-sold by these vendors (SMD/E or VDDC).
-The new CCI SMD/E controller with working scatter-gather I/O
-is supported as well.
-In particular, the following drives are supported:
-.DS
-.TS
-l l.
-FUJITSU 160M   CDC 9766 300M
-FUJITSU 330M   CDC 340M
-FUJITSU 2351 Eagle     CDC 515M
-.TE
-.DE
-.PP
-The only tape drives supported by this distribution are the
-ones attached to the Tapemaster tape controller.
-.NH 2
-Distribution format
+.Sh 1 "Introduction"
+.PP
+This document explains how to install the \*(4B Berkeley
+version of UNIX on your system.
+The filesystem format is compatible with \*(Ps
+and it will only be necessary for you to do a full bootstrap
+procedure if you are installing the release on a new machine.
+The object file formats are completely different from the System
+V release, so the most straightforward procedure for upgrading
+a System V system is to do a full bootstrap.
+.PP
+The full bootstrap procedure
+is outlined in section 2; the process starts with copying a filesystem
+image onto a new disk.
+This filesystem is then booted and used to extract the remainder of the
+system binaries and sources from the archives on the tape(s).
+.PP
+The technique for upgrading a \*(Ps system is described
+in section 3 of this document.
+The upgrade procedure involves extracting system binaries
+onto new root and
+.Pn /usr
+filesystems and merging local
+configuration files into the new system.
+User filesystems may be upgraded in place.
+Most \*(Ps binaries may be used with \*(4B in the course
+of the conversion.
+It is desirable to recompile local sources after the conversion,
+as the new compiler (GCC) provides superior code optimization.
+Consult section 3.5 for a description of some of the differences
+between \*(Ps and \*(4B.
+.Sh 2 "Distribution format"

 .PP
 The distribution comes in two formats:
 .DS
 .PP
 The distribution comes in two formats:
 .DS

-(3)\0\0 1600bpi 2400' magnetic tapes, or
-(1)\0\0 6250bpi 2400' magnetic tape
+(3)\0\0 6250bpi 2400' 9-track magnetic tapes, or
+(1)\0\0 8mm Exabyte tape

 .DE
 .DE

-Installation from scratch on any machine requires a tape unit. 
-If your machine is currently running 4.2BSD and has a network
-connection to a 4.2BSD or 4.3BSD machine with a tape drive,
-it is a simple matter to install the software from a remote
-tape drive.

 .PP
 .PP

-If you have the facilities, it is a good idea to copy the
+If you have the facilities, we \fBstrongly\fP recommend copying the

 magnetic tape(s) in the distribution kit to guard against disaster.
 magnetic tape(s) in the distribution kit to guard against disaster.

-The tapes are 9-track 1600 BPI or 6250 BPI and contain some
-1024-byte records followed by many 10240-byte records.
-There are interspersed tape marks; end-of-tape is signaled
-by a double end-of-file.
-.PP
-The first file on the tape contains a very small file system
-containing preliminary bootstrapping programs.
-This is followed by a binary image
-of a 2 megabyte ``mini root''
-file system.  Following the mini root
-file is a full dump of the root file system (see \fIdump\fP\|(8)*).
-.FS
-* References of the form X(Y) mean the subsection named
-X in section Y of the 
-.UX
-programmer's manual.
-.FE
+The tapes contain \*(Bb-byte records.
+There are interspersed tape marks;
+end-of-tape is signaled by a double end-of-file.
+The first file on the tape is architecture dependent.

 Additional files on the tape(s)
 Additional files on the tape(s)

-contain tape archive images (see
-\fItar\fP\|(1)).  See Appendix A for a description of the contents
-and format of the tape(s).
-One file contains software
-contributed by the user community; refer to the accompanying
-documentation for a description of its contents and an
-explanation of how it should be installed.
-.NH 2
-Hardware terminology
-.PP
-This section gives a short discussion of the hardware terminology
-to help you get your bearings. 
-.PP
-The Power 6/32 (and the current HCX-7 machines being shipped) use
-a VERSABUS for all i/o peripherals.  The console
-processor used for bootstrap and diagnostic purposes
-is also located on the VERSABUS.  The
-terminology you must familiarize yourself with is necessary
-to configure hardware devices on your machine.  The device naming
-conventions described here apply to the console processor; under UNIX
-device naming is simpler as you will soon see.
-.PP
-The VERSABUS is a 32-bit bus that supports devices which
-use 16-bit, 24-bit, or 32-bit addresses (or some combination).
-The type of each address placed on the VERSABUS is indicated
-by an accompanying \fIaddress modifier\fP.  In addition to the
-width of the
-address present on the bus, VERSABUS address modifiers
-may be used to indicate the privileges of the requesting
-program (.e.g the program is executing in supervisory mode).
-The 6/32's VERSABUS adapter accepts device requests with either
-16, 24, or 32-bit address modifiers and interprets the address
-as an absolute physical address in referencing main memory.
-This means that the address space for 16-bit devices overlaps
-that of 24-bit devices and both overlap the address space
-of 32-bit devices.  Devices which do not support full 32-bit
-addressing can be difficult to work with as their limited addressing
-restricts the placement of i/o buffers in main memory.  Unfortunately,
-because the VERSABUS has had limited acceptance there are
-very few good VERSABUS device controllers available; this has
-resulted in several non-VERSABUS devices being attached to the
-VERSABUS through bus-adapter cards.  Devices of this sort often
-support only 16-bit or 24-bit addressing.
-.PP
-From the Tahoe side of the VERSABUS adaptor, when memory management
-is enabled, the three address spaces are mapped so as to avoid
-overlaps.  Addresses in the range 0xffff0000 to 0xfffffff are
-used to access VERSABUS devices which use 16-bit addresses.  References
-to this region of the Tahoe address space result in a VERSABUS
-transfer with a 16-bit address generated from the lower order 16
-bits of the memory address and a ``short addressing non-privileged i/o
-access'' address modifier (0x10).  Addresses in the range 0xff000000 to
-0xffff0000 are used to access 24-bit VERSABUS devices, generating a 24-bit
-address and a ``standard addressing non-privileged data access''
-address modifier (0x01).  Finally, any other address in the
-the primary i/o adapter space, 0xf0000000 to 0xff000000, generates
-a 32-bit VERSABUS address with an ``extended addressing non-privileged
-data access'' address modifier (0xf1).  Note, however, that 32-bit
-addresses generated by references to this region result in a VERSABUS
-address with bits 31-30 set to 0.  Thus, for example, a reference to
-a device located at 0xfe000000 would result in a VERSABUS transfer
-with the address set to 0x3e000000.  A complete list of the characteristics
-of the devices supported in the system may be found in Appendix A.
-.PP
-The console processor has a set of names for devices:
-.DS
-.TS
-l l.
-FUJITSU 160M disk drives       fsd
-FUJITSU 330M disk drives       fuj
-FUJITSU 450M disk drives       egl*
-CDC 300M disk drives   smd
-CDC 340M disk drives   xfd
-CDC 515M disk drives   xsd
-Cipher tape drives     cyp
-.TE
+contain tape archive images of the system binaries and sources (see
+.Xr tar (1)\**).

 .FS
 .FS

-*\|Eagle drives are currently supported only by the HCX-7 console
-processor.
+References of the form \fIX\fP(Y) mean the entry named
+\fIX\fP in section Y of the ``UNIX Programmer's Manual''.

 .FE
 .FE

-.DE
-Devices are fully specified to the console processor with:
-.DS
-xxx(y,z)
-.DE
-where \fIxxx\fP is one of the above names (e.g. \fIxfd\fP).
-The value \fIy\fP specifies a controller to use and also
-the device; it is computed as
-.DS
-8 * \fIcontroller\fP + \fIdevice\fP
-.DE
-Thus, controller 0 (by convention the controller located at VERSABUS
-address 0xfff2400), drive 0 would have a \fIy\fP value of 0
-while controller 1 (address of 0xfff2800) drive 0 would have a \fIy\fP
-value of 4**.
-.FS
-**\|Note that this means you can not reference drives 5-15 on a
-controller; as a result we expect the console interface to
-change soon.
-.FE
-The \fIz\fP value is interpreted differently for tapes and disks;
-for disks it is a disk block, and for tapes it is a file number
-on the tape.
-.PP
-The console processor has the notion of a \fIdefault device\fP
-to use with file related commands.  The default device is specified
-according to the form shown above.  Further, the console processor,
-by default, interprets certain system files on the default disk to discover
-information about disk drives in the system.  As
-.UX
-device names are decidedly different from the names used by the
-console processor this can lead to serious confusion.  We will
-return to this problem later in \(sc4.2.1; for now you should
-simply be aware of the difference in naming conventions.
-.NH 2
-UNIX device naming
-.PP
-UNIX has a set of names for devices which are different
-from the CCI names for the devices, viz.:
-.DS
-.TS
-l l.
-VERSABUS disk drives   dk
-Cipher tape drives     cy
-.TE
-.DE
-.PP
-The standalone system, used to bootstrap the full UNIX system,
-uses device names:
-.DS
-xx(y,z)
-.DE
-where \fIxx\fP is either \fBdk\fP, or \fBcy\fP.
-The value \fIy\fP
-specifies the controller to use and also the device;  it is computed as
-.DS
-8 * \fIcontroller\fP + \fIdevice\fP
-.DE
-Thus controller 0 device 0 would have a \fIy\fP value of 0 while
-controller 1 device 0 would have a \fIy\fP value of 4.  The \fIz\fP
-value is interpreted differently for tapes and disks:
-for disks it is a disk \fIpartition\fP (in the range 0-7),
-and for tapes it is a file number on the tape.
-.PP
-Each UNIX physical disk is divided into 8 logical disk partitions,
-each of which may occupy any consecutive cylinder range on the
-physical device.  The cylinders occupied
-by the 8 partitions for each drive type
-are specified initially in section 4 of the programmers manual
-and in the disk description file /etc/disktab (c.f.
-\fIdisktab\fP(5)).
-The partition information and description of the drive geometry
-are written in the first sector of each disk
-with the \fIdisklabel\|\fP(8) program.
-Each partition may be used
-for either a raw data area such as a paging area or to store a
-UNIX file system.
+See the tape label for a description of the contents
+and format of each individual tape.
+.Sh 2 "UNIX device naming"
+.PP
+Device names have a different syntax depending on whether you are talking
+to the standalone system or a running UNIX kernel.
+The standalone system syntax is currently architecture dependent and is
+described in the various architecture specific sections as applicable.
+When not running standalone, devices are available via files in the
+.Pn /dev/
+directory.
+The file name typically encodes the device type, its logical unit and
+a partition within that unit.
+For example,
+.Pn /dev/sd2b
+refers to the second partition (``b'') of
+SCSI (``sd'') drive number ``2'', while
+.Pn /dev/rmt0
+refers to the raw (``r'') interface of 9-track tape (``mt'') unit ``0''.
+.PP
+The mapping of physical addressing information (e.g. controller, target)
+to a logical unit number is dependent on the system configuration.
+In all simple cases, where only a single controller is present, a drive
+with physical unit number 0 (e.g., as determined by its unit
+specification, either unit plug or other selection mechanism)
+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 normally
+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 easier.
+.PP
+Each UNIX physical disk is divided into at most 8 logical disk partitions,
+each of which may occupy any consecutive cylinder range on the physical
+device.  The cylinders occupied by the 8 partitions for each drive type
+are specified initially in the disk description file
+.Pn /etc/disktab
+(c.f.
+.Xr disktab (5)).
+The partition information and description of the
+drive geometry are written in one of the first sectors of each disk with the
+.Xr disklabel (8)
+program.  Each partition may be used for either a
+raw data area such as a paging area or to store a UNIX filesystem.

 It is conventional for the first partition on a disk to be used
 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.
+to store a root filesystem, from which UNIX may be bootstrapped.

 The second partition is traditionally used as a paging area, and the
 rest of the disk is divided into spaces for additional ``mounted
 The second partition is traditionally 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.
-.PP
-The disk partitions have names in the standalone system of the form
-``dk(y,z)'' with varying \fIy\fP as described above.  Thus partition
-1 of a Fujitsu Eagle on controller vd0 at drive 0 would be
-``dk(0,1)''.  When not running
-standalone, this partition would normally be available as ``/dev/dk0b''.
-Here the prefix ``/dev'' is the name of the directory where all
-``special files'' normally live, the ``dk'' serves an obvious purpose,
-the ``0'' identifies this as a partition of dk drive number ``0''
-and the ``b'' identifies this as the second partition.
-.PP
-In all simple cases, 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 normally 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.  We will not discuss that now.
-.PP
-Returning to the discussion of the standalone system, we recall
-that tapes also took two integer parameters.  In the normal case
-where the Cipher tape drive is unit 0 on the first controller, the
-files on the tape have names ``cy(0,0)'', ``cy(0,1)'', etc.
-Here ``file'' means a tape file containing a single data stream.
-The distribution tape(s) have data structures in the tape
-files and though the tape(s) contain only 9 tape files, they contain
-several thousand UNIX files.
-.NH 2
-UNIX devices: block and raw
+filesystems'' by use of one or more additional partitions.
+.Sh 2 "UNIX devices: block and raw"

 .PP
 UNIX makes a distinction between ``block'' and ``raw'' (character)
 devices.  Each disk has a block device interface where
 .PP
 UNIX makes a distinction between ``block'' and ``raw'' (character)
 devices.  Each disk has a block device interface where


@@ -313,10 +148,12 @@ the system makes the device byte addressable and you can write
 a single byte in the middle of the disk.  The system 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
 a single byte in the middle of the disk.  The system 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.
+.Pn /dev/xx0[a-h] ,
+etc., are block devices.

 There are also raw devices available.
 There are also raw devices available.

-These have names like ``/dev/rxx0a'', the
-``r'' here standing for ``raw''.
+These have names like
+.Pn /dev/rxx0[a-h] ,
+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.
 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.


@@ -326,11 +163,10 @@ to work faster.
 Raw devices are used when making new filesystems,
 when checking unmounted filesystems,
 or for copying quiescent filesystems.
 Raw devices are used when making new filesystems,
 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.
+The block devices are used to mount filesystems.

 .PP
 You should be aware that it is sometimes important whether to use
 .PP
 You should be aware that it is sometimes important whether to use

-the character device (for efficiency) or not (because it wouldn't
+the character device (for efficiency) or not (because it would not

 work, e.g. to write a single byte in the middle of a sector).
 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
+Do not change the instructions by using the wrong type of device

 indiscriminately.
 indiscriminately.