karels, bostic editing
authorMike Karels <karels@ucbvax.Berkeley.EDU>
Mon, 18 Jul 1988 00:31:51 +0000 (16:31 -0800)
committerMike Karels <karels@ucbvax.Berkeley.EDU>
Mon, 18 Jul 1988 00:31:51 +0000 (16:31 -0800)
SCCS-vsn: share/doc/smm/01.setup/0.t 1.2
SCCS-vsn: share/doc/smm/01.setup/1.t 1.2
SCCS-vsn: share/doc/smm/01.setup/2.t 1.2

usr/src/share/doc/smm/01.setup/0.t
usr/src/share/doc/smm/01.setup/1.t
usr/src/share/doc/smm/01.setup/2.t

index 504839a..fa38db6 100644 (file)
@@ -1,20 +1,29 @@
-.\" Copyright (c) 1980 Regents of the University of California.
+.\" Copyright (c) 1988 Regents of the University of California.
 .\" All rights reserved.  The Berkeley software License Agreement
 .\" specifies the terms and conditions for redistribution.
 .\"
 .\"    @(#)0.t 6.1 (Berkeley) 5/13/86
 .\"
 .\" All rights reserved.  The Berkeley software License Agreement
 .\" specifies the terms and conditions for redistribution.
 .\"
 .\"    @(#)0.t 6.1 (Berkeley) 5/13/86
 .\"
-.EH 'SMM:1-%''Installing and Operating 4.3BSD on the Tahoe'
-.OH 'Installing and Operating 4.3BSD on the Tahoe''SMM:1-%'
-.ds 4B 4.3BSD
+.EH 'SMM:1-%''Installing and Operating 4.3BSD-tahoe UNIX on the Tahoe'
+.OH 'Installing and Operating 4.3BSD-tahoe UNIX on the Tahoe''SMM:1-%'
+.ds 4B 4.3BSD-tahoe
+.nr Th 1               \" Tahoe version
+.ds Mc Tahoe
+.ds mC tahoe
+.ds Dk dk
+.ds Dn Eagle
+.ds Pa c
+.ds Ps 4.3BSD-beta
 .bd S B 3
 .TL
 .bd S B 3
 .TL
-Installing and Operating \*(4B on the Tahoe
+Installing and Operating \*(4B UNIX* on the Tahoe
 .br
 .br
-April 1, 1986
+July 14, 1988
 .AU
 Samuel J. Leffler
 .AU
 .AU
 Samuel J. Leffler
 .AU
+Keith Bostic
+.AU
 Michael J. Karels
 .AU
 Marshall Kirk McKusick
 Michael J. Karels
 .AU
 Marshall Kirk McKusick
@@ -33,19 +42,16 @@ UNIX\\$1
 .AB
 .PP
 .FS
 .AB
 .PP
 .FS
-* Tahoe is a trademark of Computer Consoles Incorporated.
-.FE
-.FS
-** \s-2UNIX\s0 is a Trademark of Bell Laboratories.
+*\s-2UNIX\s0 is a register trademark of AT&T in the USA and other countries.
 .FE
 This document contains instructions for the
 installation and operation of the
 \*(4B release of
 .FE
 This document contains instructions for the
 installation and operation of the
 \*(4B release of
-.UX **
+.UX
 as distributed by The University of California at Berkeley
 as distributed by The University of California at Berkeley
-for the Tahoe* (CCI Power 6/32 and similar machines).
+for the Tahoe (CCI Power 6/32 and similar machines).
 .PP
 .PP
-It discusses procedures for installing UNIX on a new Tahoe,
+It discusses procedures for installing UNIX on a new machine,
 and for upgrading an existing 4.2BSD Tahoe 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 for upgrading an existing 4.2BSD Tahoe 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,
index 7f2c798..f41c785 100644 (file)
@@ -1,4 +1,4 @@
-.\" Copyright (c) 1980 Regents of the University of California.
+.\" Copyright (c) 1988 Regents of the University of California.
 .\" All rights reserved.  The Berkeley software License Agreement
 .\" specifies the terms and conditions for redistribution.
 .\"
 .\" All rights reserved.  The Berkeley software License Agreement
 .\" specifies the terms and conditions for redistribution.
 .\"
 .R
 .NL
 .PP
 .R
 .NL
 .PP
-This document explains how to install the \*(4B release of the Berkeley
+This document explains how to install 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
 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
+distributed by Computer Consoles Inc. (CCI) was 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.
 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
+The System V UNIX systems distributed by CCI, Unisys (Sperry) and Harris
 are also derived from 4.2BSD, but only the network and filesystem
 are also derived from 4.2BSD, but only the network and filesystem
-remain compatible with 4.2 and 4.3.
+remain compatible with \*(4B.
 The object file formats are completely different in the System V
 releases.
 Thus, the most straightforward procedure for upgrading a System V
 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
+system is to perform a full bootstrap.
+.PP
+The full bootstrap procedure
 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
 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
@@ -42,28 +45,30 @@ 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
 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
+The technique for upgrading a 4.2 or beta-release 4.3BSD system is described
 in chapter 3 of this document.
 in chapter 3 of this document.
-As 4.3BSD is upward-compatible with 4.2BSD,
+As \*(4B is completely compatible with the beta release,
+and sufficiently compatible with the vendor-supplied 4.2BSD releases,
 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
 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.
+into the new system.  User filesystems may be upgraded in place.
+All 4.3BSD-beta binaries may be used with \*(4B in the course
+of the conversion.
+It is desirable to recompile local sources after the conversion,
+as the compilers have had many fixes installed.
+However, due to significant incompatibilities between
+the vendor-derived versions of 4.2BSD and the Berkeley \*(4B release, many
+4.2BSD binary images will not function properly.  For such programs it
+will be both necessary and desirable to recompile this software after
+the conversion.  Consult section 3 for a description of the differences
+between \*(4B and the previous vendor-supplied systems for the Tahoe.
 .NH 2
 Hardware supported
 .PP
 .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).
+This distribution can be booted on a CCI Power 6/32, Harris HCX-7,
+Unisys (Sperry) 7000/40, or ICL Clan 7 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:
 The new CCI SMD/E controller with working scatter-gather I/O
 is supported as well.
 In particular, the following drives are supported:
@@ -73,46 +78,43 @@ l l.
 FUJITSU 160M   CDC 9766 300M
 FUJITSU 330M   CDC 340M
 FUJITSU 2351 Eagle     CDC 515M
 FUJITSU 160M   CDC 9766 300M
 FUJITSU 330M   CDC 340M
 FUJITSU 2351 Eagle     CDC 515M
+Maxtor 340M
 .TE
 .DE
 .PP
 The only tape drives supported by this distribution are the
 .TE
 .DE
 .PP
 The only tape drives supported by this distribution are the
-ones attached to the Tapemaster tape controller.
+ones attached to the Ciprico Tapemaster tape controller.
 .NH 2
 Distribution format
 .PP
 The distribution comes in two formats:
 .DS
 .NH 2
 Distribution format
 .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 1600bpi  2400'  9-track magnetic tapes, or
+(1)\0\0 6250bpi  2400'  9-track magnetic 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.
+Installation from scratch on any machine requires a tape unit.  If your
+machine is currently running 4.2 or 4.3BSD-beta and has a network connection
+to a 4.2 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)*).
+The tapes 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.  The first file
+on the tape is a very small file system containing
+preliminary bootstrapping programs.  This is followed by a binary image
+of an approximately 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
 .FS
-* References of the form X(Y) mean the subsection named
-X in section Y of the 
+\ * References of the form \fIX\fP(Y) mean the entry named
+\fIX\fP in section Y of the
 .UX
 programmer's manual.
 .FE
 Additional files on the tape(s)
 .UX
 programmer's manual.
 .FE
 Additional files on the tape(s)
-contain tape archive images (see
+contain tape archive images of the system binaries and sources (see
 \fItar\fP\|(1)).  See Appendix A for a description of the contents
 and format of the tape(s).
 One file contains software
 \fItar\fP\|(1)).  See Appendix A for a description of the contents
 and format of the tape(s).
 One file contains software
@@ -122,57 +124,67 @@ explanation of how it should be installed.
 .NH 2
 Hardware terminology
 .PP
 .NH 2
 Hardware terminology
 .PP
-This section gives a short discussion of the hardware terminology
+This section gives a short discussion of hardware terminology
 to help you get your bearings. 
 .PP
 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
+The Power 6/32 (and most related 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 device naming
 conventions described here apply to the console processor; under UNIX
 conventions described here apply to the console processor; under UNIX
-device naming is simpler as you will soon see.
+device naming is considerably simpler.
 .PP
 .PP
-The VERSABUS is a 32-bit bus that supports devices which
+The VERSAbus is a 32-bit bus that supports devices which
 use 16-bit, 24-bit, or 32-bit addresses (or some combination).
 use 16-bit, 24-bit, or 32-bit addresses (or some combination).
-The type of each address placed on the VERSABUS is indicated
+The type of each address placed on the VERSAbus is indicated
 by an accompanying \fIaddress modifier\fP.  In addition to the
 width of the
 by an accompanying \fIaddress modifier\fP.  In addition to the
 width of the
-address present on the bus, VERSABUS address modifiers
+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).
 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
+The 6/32's VERSAbus adapter accepts device requests with either
+16, 24, or 32-bit address modifiers.
+16-bit addresses are used to access control registers
+for VERSAbus devices.
+24-bit addresses are used to access up to one megabyte of VERSAbus
+local memory or device shared memory
+as well as the first 15Mb of main memory.
+24-bit addresses are used for DMA by some peripherals,
+interpreting the address
 as an absolute physical address in referencing main memory.
 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
+Other devices use 32-bit addressing, allowing them to access all
+of main memory.
+This means that the address space for 24-bit devices overlaps
+that of 32-bit devices.
+Devices which do not support full 32-bit
 addressing can be difficult to work with as their limited addressing
 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.
+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 20-bit or 24-bit addressing.
 .PP
 .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
+From the Tahoe side of the VERSAbus adaptor,
+the three address spaces are mapped so as to avoid
+overlaps.  Physical 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
 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
+bits of the memory address and a ``short addressing non-privileged I/O
 access'' address modifier (0x10).  Addresses in the range 0xff000000 to
 access'' address modifier (0x10).  Addresses in the range 0xff000000 to
-0xffff0000 are used to access 24-bit VERSABUS devices, generating a 24-bit
+0xffff0000 are used to access 24-bit VERSAbus devices, generating a 24-bit
 address and a ``standard addressing non-privileged data access''
 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
+address modifier (0x01).
+Within this range, addresses from 0xfff00000 to 0xffff0000 refer
+to VERSAbus local memory used by devices (such as the VIOC)
+for shared communication areas.
+Finally, any other address in the
+the primary I/O adapter space, 0xc0000000 to 0xff000000, generates
+a 32-bit VERSAbus address with an ``extended addressing non-privileged
 data access'' address modifier (0xf1).  Note, however, that 32-bit
 data access'' address modifier (0xf1).  Note, however, that 32-bit
-addresses generated by references to this region result in a VERSABUS
+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
 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
+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
 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
@@ -182,15 +194,16 @@ The console processor has a set of names for devices:
 l l.
 FUJITSU 160M disk drives       fsd
 FUJITSU 330M disk drives       fuj
 l l.
 FUJITSU 160M disk drives       fsd
 FUJITSU 330M disk drives       fuj
-FUJITSU 450M disk drives       egl*
+FUJITSU 450M disk drives       egl**
 CDC 300M disk drives   smd
 CDC 340M disk drives   xfd
 CDC 515M disk drives   xsd
 CDC 300M disk drives   smd
 CDC 340M disk drives   xfd
 CDC 515M disk drives   xsd
+MXD Maxtor 340M disk drives    mxd
 Cipher tape drives     cyp
 .TE
 .FS
 Cipher tape drives     cyp
 .TE
 .FS
-*\|Eagle drives are currently supported only by the HCX-7 console
-processor.
+**\|Eagle drives are not supported by the console processor on all tahoe
+machines.
 .FE
 .DE
 Devices are fully specified to the console processor with:
 .FE
 .DE
 Devices are fully specified to the console processor with:
@@ -203,12 +216,12 @@ the device; it is computed as
 .DS
 8 * \fIcontroller\fP + \fIdevice\fP
 .DE
 .DS
 8 * \fIcontroller\fP + \fIdevice\fP
 .DE
-Thus, controller 0 (by convention the controller located at VERSABUS
+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
 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**.
+value of 4*.
 .FS
 .FS
-**\|Note that this means you can not reference drives 5-15 on a
+*\|Note that this means you can not reference drives 4-15 on a
 controller; as a result we expect the console interface to
 change soon.
 .FE
 controller; as a result we expect the console interface to
 change soon.
 .FE
@@ -224,7 +237,7 @@ 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
 .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
+return to this problem later in section 4; for now you should
 simply be aware of the difference in naming conventions.
 .NH 2
 UNIX device naming
 simply be aware of the difference in naming conventions.
 .NH 2
 UNIX device naming
@@ -234,72 +247,59 @@ from the CCI names for the devices, viz.:
 .DS
 .TS
 l l.
 .DS
 .TS
 l l.
-VERSABUS disk drives   dk
+VERSAbus disk drives   dk
 Cipher tape drives     cy
 .TE
 .DE
 .PP
 The standalone system, used to bootstrap the full UNIX system,
 Cipher tape drives     cy
 .TE
 .DE
 .PP
 The standalone system, used to bootstrap the full UNIX system,
-uses device names:
+uses device names of the form:
 .DS
 .DS
-xx(y,z)
+xx(c,d,p)
 .DE
 .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.
+where \fIxx\fP is the device type, normally \fIdk\fP or \fIcy\fP.  The
+value \fIc\fP specifies the controller to use, and \fId\fP specifies
+the device.  The \fIp\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 offset on the tape.  Thus, partition
+1 of a ``dk'' type disk drive on controller vd0 at drive 0 would be
+``dk(0,0,1)''.  Normally the controller will be controller 0; it
+may therefore be omitted from the device specification, and most of
+the examples in this document reflect this.  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 the obvious purpose,
+the ``0'' identifies this as a partition of dk drive number ``0'' and
+the ``b'' identifies this as the second partition.
 .PP
 .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.
+In all simple cases, where only a single controller is present, a drive
+with unit number 0 (determined by 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.
+.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 /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.
 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 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
 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 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
 Returning to the discussion of the standalone system, we recall
-that tapes also took two integer parameters.  In the normal case
+that tapes also took three integer parameters.  In the normal case
 where the Cipher tape drive is unit 0 on the first controller, the
 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.
+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
 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
@@ -313,9 +313,9 @@ 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.
+``/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
+These have names like ``/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;
 ``r'' here standing for ``raw''.
 Raw devices bypass the buffer cache and use DMA directly to/from
 the program's I/O buffers;
index 38ac9ea..362a557 100644 (file)
@@ -1,4 +1,4 @@
-.\" Copyright (c) 1980 Regents of the University of California.
+.\" Copyright (c) 1988 Regents of the University of California.
 .\" All rights reserved.  The Berkeley software License Agreement
 .\" specifies the terms and conditions for redistribution.
 .\"
 .\" All rights reserved.  The Berkeley software License Agreement
 .\" specifies the terms and conditions for redistribution.
 .\"
@@ -25,7 +25,7 @@ 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 you will
 have to do a full bootstrap.
 to get the kernel supplied with this distribution running on your machine.
 If you are not currently running 4.2BSD you will
 have to do a full bootstrap.
-Chapter 3 describes how to upgrade an existing 4.2BSD system.
+Chapter 3 describes how to upgrade a 4.2BSD system.
 An understanding of the operations 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
 An understanding of the operations 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
@@ -37,12 +37,12 @@ The tape bootstrap procedure used to create a
 working system involves the following major
 steps:
 .IP 1)
 working system involves the following major
 steps:
 .IP 1)
-Format a disk pack with the \fIvdformat\fP program.
+Format a disk pack with the \fIvdformat\fP program, if necessary.
 .IP 2)
 Copy a ``mini root'' file system from the
 tape onto the swap area of the disk.
 .IP 3)
 .IP 2)
 Copy a ``mini root'' file system from the
 tape onto the swap area of the disk.
 .IP 3)
-Boot the UNIX system on the ``mini root''.
+Boot the UNIX system on the ``mini root.''
 .IP 4)
 Restore the full root file system using \fIrestore\fP\|(8).
 .IP 5)
 .IP 4)
 Restore the full root file system using \fIrestore\fP\|(8).
 .IP 5)
@@ -56,16 +56,20 @@ with \fItar\fP\|(1).
 Extract the system and utility files and contributed software
 as desired.
 .PP
 Extract the system and utility files and contributed software
 as desired.
 .PP
-The following sections describe the above steps in detail.
-In these sections references to disk drives are of the
-form \fIxx\fP\|(\fIn\fP,\fIm\fP)
-and references to files on tape drives are of the form
-\fIyy\fP\|(\fIn\fP,\fIm\fP) where \fIxx\fP and \fIyy\fP
-are names described in section 1.4 and \fIn\fP
-and \fIm\fP are the unit and offset numbers described in
-section 1.4.  Commands
-you are expected to type are shown in Roman, while that
-information printed by the system is shown emboldened.
+The following sections describe the above steps in detail.  In these
+sections references to disk drives are of the form \fIxx\fP\|(\fId\fP,
+\fIp\fP) and references to files on tape drives are of the form
+\fIxx\fP\|(\fIc\fP,\fId\fP, \fIp\fP)
+where \fIxx\fP are device types described in section 1.4,
+\fIc\fP is the (optional) controller unit number,
+\fId\fP is the drive unit number, and \fIp\fP is a disk partition
+or tape file offset numbers as described in section 1.4.
+For the sake of simplicity, all disk examples will use the disk type
+``dk'' and all tape examples will similarly use ``cy'';
+the examples assume drive 0, partition 0.
+Commands you
+are expected to type are shown in italics, while that information
+printed by the system is shown emboldened.
 .PP
 If you encounter problems while following the instructions in
 this part of the document, refer to Appendix B for help in
 .PP
 If you encounter problems while following the instructions in
 this part of the document, refer to Appendix B for help in
@@ -79,11 +83,10 @@ The
 .I vdformat
 program included in the distribution, or a vendor supplied
 formatting program, may be used to format disks if this has not
 .I vdformat
 program included in the distribution, or a vendor supplied
 formatting program, may be used to format disks if this has not
-already been done.
-The
-.I vdformat
-program is capable of formatting
-any of the disk drives listed in \(sc1.1.
+already been done.  The \fIvdformat\fP program is capable of formatting
+any of the disk drives listed in section 1.1, when booting from tape;
+when booting from disk, it supports any drive listed in
+\fI/etc/disktab\fP.
 .PP
 To load the \fIvdformat\fP program, perform the following steps.
 .DS
 .PP
 To load the \fIvdformat\fP program, perform the following steps.
 .DS
@@ -92,12 +95,12 @@ lw(2i) l.
 (machine powered up)
 \fBMIB POC\fP
 \fBType '#' to cancel boot\fP
 (machine powered up)
 \fBMIB POC\fP
 \fBType '#' to cancel boot\fP
-#      (cancel automatic reboot)
-\fBCP [a10.h0]#>\fP\|h (halt the cpu)
-\fB#>\|\fPy    (initialize the machine)
-\fB#>\|\fPfd cyp(0,0)  (make cypher default device)
-\fB#>\|\fPp23 3. \fB00000000\fP        (set boot flags)
-\fB#>\|\fPfb   (boot machine)
+\fI#\fP        (cancel automatic reboot)
+\fBCP [a10.h0]#>\fP\fI\|h\fP   (halt the cpu)
+\fB#>\|\fP\fIy.\fP     (initialize the machine)
+\fB#>\|\fP\fIfd cyp(0,0)\fP    (make cypher default device)
+\fB#>\|\fP\fIp23 3.\fP \fB00000000\fP  (set boot flags)
+\fB#>\|\fP\fIfb\fP     (boot machine)
 \fBcyp(0,0)/etc/fstab\fP
 \fBCP cold boot\fP
 \fB4 way interleave set\fP
 \fBcyp(0,0)/etc/fstab\fP
 \fBCP cold boot\fP
 \fB4 way interleave set\fP
@@ -115,15 +118,10 @@ lw(2i) l.
 \fBBOOT SYSTEM cyp(0,0)/boot\fP
 
 \fBBoot\fP
 \fBBOOT SYSTEM cyp(0,0)/boot\fP
 
 \fBBoot\fP
-\fB:\fRcy(0,0)stand/vdformat   (load and run from first tape file)
+\fB:\fIcy(0,0)stand/vdformat\fR        (load and run from first tape file)
+\fB52224+17408+1177716 start 0x1000\fP
+\fBVDFORMAT     Berkeley Version 1.6\fP
 .TE
 .TE
-.DE
-.PP
-The \fIvdformat\fP program should now be running and awaiting your input:
-.DS
-\fB:\fPcy(0,0)stand/vdformat
-\fB50176+14336+776780 start 0x1000\fP
-\fBVDFORMAT    Version 3.0\fP
 
 \fBcontroller 0: smd\fP
 \fBcontroller 1: smd-e\fP
 
 \fBcontroller 0: smd\fP
 \fBcontroller 1: smd-e\fP
@@ -132,9 +130,11 @@ The \fIvdformat\fP program should now be running and awaiting your input:
 
 \fBvdformat>\fP
 .DE
 
 \fBvdformat>\fP
 .DE
+.PP
+The \fIvdformat\fP program should now be running and awaiting your input.
 If you made a mistake loading the program off the tape
 If you made a mistake loading the program off the tape
-you should get either the ``:'' prompt again from the
-boot program or the ``#>'' prompt from the console
+you should get either the ``:'' prompt again (from the
+boot program) or the ``#>'' prompt from the console
 processor.  In either case you can retype the appropriate
 command to try again.
 If something else happened, you may have a bad distribution
 processor.  In either case you can retype the appropriate
 command to try again.
 If something else happened, you may have a bad distribution
@@ -148,25 +148,24 @@ installed in the machine.  Old VDDC controllers which
 support only SMD drives are indicated
 as ``smd'' while newer controllers capable of supporting both
 SMD and extended-SMD drives are tagged as ``smd-e''. 
 support only SMD drives are indicated
 as ``smd'' while newer controllers capable of supporting both
 SMD and extended-SMD drives are tagged as ``smd-e''. 
-Remember \fIvdformat\fP works only with the drives listed above.
 \fIVdformat\fP
 will prompt for the information required as shown below.
 If you err in answering questions,
 \fIVdformat\fP
 will prompt for the information required as shown below.
 If you err in answering questions,
-``Delete'' erases the last character typed, and ``^U'' erases
+``Delete'' or backspace erase the last character typed, and ``^U'' erases
 the current input line.  At any point you can ask for
 assistance by typing ``help''; \fIvdformat\fP will list
 the possible answers to the current question.
 .DS
 the current input line.  At any point you can ask for
 assistance by typing ``help''; \fIvdformat\fP will list
 the possible answers to the current question.
 .DS
-\fBvdformat>\fP\|format
-  \fBFormat on which controllers?\fP\|1
-    \fBDrives on controller 1?\fP\|0
-      \fBNumber of patterns to use while verifying?\fP\|1
-      \fBDrive type for controller 1, drive 0?\fP\|egl
-        \fBModule serial number for controller 1, drive 0?\fP\|1
-\fBvdformat>\fP\|list
+\fBvdformat>\fP\|\fIformat\fP
+  \fBFormat on which controllers?\fP\|\fI1\fP
+    \fBDrives on controller 1?\fP\|\fI0\fP
+      \fBNumber of patterns to use while verifying?\fP\|\fI1\fP
+      \fBDrive type for controller 1, drive 0?\fP\|\fIegl\fP
+        \fBModule serial number for controller 1, drive 0?\fP\|\fI1\fP
+\fBvdformat>\fP\|\fIlist\fP
   \fBThe following operations will occur when Start is issued:\fP
     \fBFormat: Controller 1, drive 0, type EGL.\fP
   \fBThe following operations will occur when Start is issued:\fP
     \fBFormat: Controller 1, drive 0, type EGL.\fP
-\fBvdformat>\fP\|start
+\fBvdformat>\fP\|\fIstart\fP
 \fBStarting format on controller 1, drive 0, type EGL.\fP
 (\fIbad sectors will be indicated\fP)
 \fBvdformat>\fP
 \fBStarting format on controller 1, drive 0, type EGL.\fP
 (\fIbad sectors will be indicated\fP)
 \fBvdformat>\fP
@@ -175,12 +174,12 @@ Once the root device has been formatted, \fIvdformat\fP
 will prompt for another command.
 Return to the bootstrap by typing
 .DS
 will prompt for another command.
 Return to the bootstrap by typing
 .DS
-\fBvdformat>\fP\|exit
+\fBvdformat>\fP\|\fIexit\fP
 .DE
 or halt the machine by
 typing ``~h''.
 .DS
 .DE
 or halt the machine by
 typing ``~h''.
 .DS
-\fBvdformat>\fP ~h
+\fBvdformat>\fP \fI~h\fP
 \fB#>\|\fP
 .DE
 .PP
 \fB#>\|\fP
 .DE
 .PP
@@ -191,38 +190,32 @@ off a disk drive as described in \(sc6.1.
 .NH 3
 Step 2: copying the mini-root file system
 .PP
 .NH 3
 Step 2: copying the mini-root file system
 .PP
-The second step is to run a simple program,
-\fIcopy\fP, 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 partition.
-Disk 0 is normally used for this operation when doing an initial
-boot.
-Another disk may be substituted if necessary,
-although several modifications to the procedure may be needed
-to create special files for the alternate disk.
-The actual disk number should be substituted for the \fIx\fP below.
-\fICopy\fP is loaded just as the
-\fIvdformat\fP program was loaded;
-if you don't have the bootstrap running,
-repeat the above instructions until you see the
-prompt from Boot (a colon), and then:
+The second step is to run a simple program, \fIcopy\fP, to copy a
+small root file system into the \fBsecond\fP partition of the disk.  (Note
+that the disk partitions used by \*(4B may not correspond to those
+used by vendor supplied software.)  This file system will serve as the
+base for creating the actual root file system to be restored.  The
+generic 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 partition.  Disk 0 is normally used for
+this operation; this is reflected in the example procedure.  Another disk
+may be substituted if necessary, although several modifications will
+be necessary to create special files for the alternate disk.  \fICopy\fP
+is loaded just as the \fIvdformat\fP program was loaded; if you don't
+have the bootstrap running, repeat the previous instructions until you
+see the prompt from boot (a colon), and then:
 .DS
 .TS
 lw(2i) l.
 .DS
 .TS
 lw(2i) l.
-(copy mini root file system)
-\fB:\|\fPcy(0,0)copy   (load and run copy program)
-\fBFrom:\fP cy(0,1)    (unit 0, second tape file)
-\fBTo:\fP dk(\fIx\fP,1)        (mini root is on drive \fIx\fP; second partition)
+\fB:\|\fP\fIcy(0,0)copy\fP     (load and run copy program)
+\fBFrom:\fP \fIcy(0,1)\fP      (tape drive unit 0, second tape file)
+\fBTo:\fP \fIdk(0,1)\fP        (disk drive unit 0, second disk partition)
 \fBCopy completed: 205 records copied\fP
 \fBBoot\fP
 \fB:\fP
 .TE
 \fBCopy completed: 205 records copied\fP
 \fBBoot\fP
 \fB:\fP
 .TE
-(As above, `delete' erases characters and `^U' erases lines.)
 .DE
 .DE
+As before, `delete' or backspace erase characters and `^U' erases lines.
 .NH 3
 Step 3: booting from the mini-root file system
 .PP
 .NH 3
 Step 3: booting from the mini-root file system
 .PP
@@ -236,7 +229,7 @@ it running.  At the colon prompt:
 .DS
 .TS
 lw(2i) l.
 .DS
 .TS
 lw(2i) l.
-\fB: \fPdk(\fIx\fP,1)vmunix    (bring in \fIvmunix\fP off mini root)
+\fB: \fP\fIdk(0,1)vmunix\fP    (get \fIvmunix\fP from disk drive 0, second partition)
 .TE
 .DE
 The standalone boot program should then read the system from
 .TE
 .DE
 The standalone boot program should then read the system from
@@ -244,22 +237,23 @@ the mini root file system you just created, and the system should boot:
 .DS
 .B
 271944+78848+92812 start 0x12e8
 .DS
 .B
 271944+78848+92812 start 0x12e8
-4.3 BSD UNIX #1: Wed Apr  9 23:33:59 PST 1985
-    sam@okeeffe.berkeley.edu:/usr/src/sys/GENERIC
-real mem  = \fIxxx\fP
-avail mem = \fIyyy\fP
-\fI\&... information about available devices ...\fP
+4.3 BSD #1: Sat Jun  4 17:11:42 PDT 1988
+       (karels@okeeffe.Berkeley.EDU:/usr/src/sys/GENERIC)
+real mem  = xxx
+avail mem = ###
+using ### buffers containing ### bytes of memory
+(... information about available devices ...)
 root device? 
 .R
 .DE
 .PP
 root device? 
 .R
 .DE
 .PP
-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.
+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.
 .PP
 UNIX itself then runs for the first time and begins by printing out a banner
 identifying the release and
 .PP
 UNIX itself then runs for the first time and begins by printing out a banner
 identifying the release and
@@ -271,20 +265,19 @@ messages give the
 amount of real (physical) memory and the
 memory available to user programs
 in bytes.
 amount of real (physical) memory and the
 memory available to user programs
 in bytes.
-For example, if your machine has only 512K bytes of memory, then
-\fIxxx\fP will be 520192, 4096 bytes less than 512K.
-The system reserves the last 4096 bytes of memory for use in
-error logging and doesn't count it as part of real memory.
+For example, if your machine has 16Mb bytes of memory, then
+\fBxxx\fP will be 16777216.
 .PP
 The messages that come out next show what devices were found on
 the current processor.  These messages are described in
 \fIautoconf\fP\|(4).
 The distributed system may not have
 .PP
 The messages that come out next show what devices were found on
 the current processor.  These messages are described in
 \fIautoconf\fP\|(4).
 The distributed system may not have
-found all the communications devices you have (vioc's),
+found all the communications devices you have (VIOC's or MPCC's),
 or all the mass storage peripherals you have, especially
 if you have more than
 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.
+two of anything.  You will correct this when you create
+a description of your machine from which to configure a site-dependent
+version of UNIX.
 The messages printed at boot here contain much of the information
 that will be used in creating the configuration.
 In a correctly configured system most of the information
 The messages printed at boot here contain much of the information
 that will be used in creating the configuration.
 In a correctly configured system most of the information
@@ -293,21 +286,20 @@ is printed out at boot time as the system verifies that each device
 is present.
 .PP
 The \*(lqroot device?\*(rq prompt was printed by the system 
 is present.
 .PP
 The \*(lqroot device?\*(rq prompt was printed by the system 
-and is now asking you for the name of the root file system to use.
+to ask you for the name of the root file system to use.
 This happens because the distribution system is a \fIgeneric\fP
 system, i.e. it can be bootstrapped on a Tahoe cpu with its root device
 This happens because the distribution system is a \fIgeneric\fP
 system, i.e. it can be bootstrapped on a Tahoe cpu with its root device
-and paging area on any available disk drive.  You should respond
-to the root device question with \fIxx\fP0*.  This response
-supplies two pieces of information:
-first, \fIxx\fP0 shows that the disk it is running on is drive
-0 of type \fIxx\fP, secondly the \*(lq*\*(rq shows that the system is
-running \*(lqatop\*(rq the paging area.  The latter is most important,
-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 question when it is bootstrapped.
+and paging area on any available disk drive.  You should respond to the
+root device question with ``dk0*''.  This response supplies two pieces
+of information: first, ``dk0'' shows that the disk it is running on is
+drive 0 of type ``dk'', and, secondly, the \*(lq*\*(rq shows that the
+system is running \*(lqatop\*(rq the paging area.  The latter is
+extremely important, 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 question when it is
+bootstrapped.
 .DS
 .DS
-\fBroot device?\fP \fIxx\fP0*
+\fBroot device?\fP \fIdk0*\fP
 WARNING: preposterous time in file system \-\- CHECK AND RESET THE DATE!
 \fBerase ^?, kill ^U, intr ^C\fP
 \fB#\fP
 WARNING: preposterous time in file system \-\- CHECK AND RESET THE DATE!
 \fBerase ^?, kill ^U, intr ^C\fP
 \fB#\fP
@@ -321,29 +313,34 @@ line erase, and interrupt characters have been set.
 Step 4: restoring the root file system
 .PP
 UNIX is now running,
 Step 4: restoring the root file system
 .PP
 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 \*(lqroot\*(rq.  To complete installation
-of the bootstrap system one step remains:  the root
-file system must be created.
-.PP
-If the root file system is to reside on a disk other than
-unit 0 (as the information printed out
-during autoconfiguration 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 dk1, you must create /dev/rdk1a and /dev/dk1a using 
-\fImknod\fP(8) or the MAKEDEV script in /dev.
-.PP
-To create the root file system the shell script \*(lqxtr\*(rq
+and the \fIUNIX Programmer's manual\fP applies.  The ``#'' is the prompt
+from the Bourne shell, and lets you know that you are the super-user,
+whose login name is \*(lqroot\*(rq.
+.PP
+To complete installation of the bootstrap system one step remains: the
+root file system must be created.  If the root file system is to reside
+on a disk other than unit 0, you will have to create the necessary special
+files in /dev and use the appropriate value in the following example
+procedures.
+.PP
+For example, if the root must be placed on dk1, you should
+create /dev/rdk1a and /dev/dk1a using the MAKEDEV script in /dev
+as follows:
+.DS
+\fB#\fP\|\fIcd /dev; MAKEDEV dk1\fP
+.DE
+.PP
+To actually create the root file system the shell script \*(lqxtr\*(rq
 should be run:
 .DS
 should be run:
 .DS
-\fB#\|\fPdisk=dk\fIx\fP tape=cy xtr
+\fB#\fP\|\fIdisk=dk0 tape=cy xtr\fP
+(Note, ``dk0'' specifies both the disk type and the unit number.  Modify
+as necessary.)
 .DE
 .DE
+.PP
 This will generate many messages regarding the construction
 of the file system and the restoration of the tape contents,
 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:
+but should eventually stop with the message:
 .DS
  ...
 \fBRoot filesystem extracted\fP
 .DS
  ...
 \fBRoot filesystem extracted\fP
@@ -355,42 +352,46 @@ Step 5: rebooting the completed root file system
 With the above work completed, all that is left is to reboot:
 .DS
 .ta 3.5i
 With the above work completed, all that is left is to reboot:
 .DS
 .ta 3.5i
-\fB#\|\fPsync  (synchronize file system state)
-\fB#\|\fP~h    (halt cpu)
-\fB#>\|\fPy    (initialize machine)
-\fB#>\|\fPp23 2        (set boot flags)
-\fB#>\|\fPfr boot
-\fI\&...(boot program is eventually loaded)...\fP
+\fB#\|\fP\fIsync\fP    (synchronize file system state)
+\fB#\|\fP\fI~h\fP      (halt cpu)
+\fB#>\|\fP\fIy.\fP     (initialize machine)
+\fB#>\|\fP\fIp23 2.\fP (set boot flags)
+\fB#>\|\fP\fIfr boot\fP
+\fB\&...(boot program is eventually loaded)...\fP
 \fBBoot\fP
 \fBBoot\fP
-\fB:\fP dk(\fIx\fP,0)vmunix    (\fIvmunix\fP brought in off root)
-\fB271944+78848+92812 start 0x12e8
-\fB4.3 BSD UNIX #1: Wed Apr  9 23:33:59 PST 1985
-\fB    karels@okeeffe.berkeley.edu:/usr/src/sys/GENERIC
-\fBreal mem  = \fIxxx\fR
-\fBavail mem = \fIyyy\fR
-\fI\&... information about available devices ...\fP
-\fBroot on xx0\fP
-WARNING: preposterous time in file system \-\- CHECK AND RESET THE DATE!
-\fBerase ^?, kill ^U, intr ^C\fP
-\fB#\fP
+\fB:\fP \fIdk(0,0)vmunix\fP    (\fIvmunix\fP from disk drive 0, partition 0)
+(Modify unit number as necessary.)
+.B
+.nf
+271944+78848+92812 start 0x12e8
+4.3 BSD #1: Sat Jun  4 17:11:42 PDT 1988
+        (karels@okeeffe.Berkeley.EDU:/usr/src/sys/GENERIC)
+real mem  = ###
+avail mem = ###
+using ### buffers containing ### bytes of memory
+(... information about available devices ...)
+root on dk0
+WARNING: preposterous time in file system -- CHECK AND RESET THE DATE!
+erase ^?, kill ^U, intr ^C
+#
+.fi
 .DE
 .DE
+.R
 .PP
 .PP
-If the root device selected by the kernel is not correct,
-it is necessary to reboot again using the option to ask for the root
-device.  On the Tahoe use ``p23 3''.
-At the prompt from the bootstrap, use the same device specification
-above: dk(\fIx\fP,0)vmunix.
-Then, to the question ``root device?,''
-respond with dk0.
+If the root device selected by the kernel is not correct, it is necessary
+to reboot again using the option to ask for the root device.  On the Tahoe
+use ``\fIp23 3.\fP''.  At the prompt from the bootstrap, use the same
+disk driver unit specification as used above: ``\fIdk(0,0)vmunix\fP''.
+Then, to the question ``root device?,'' respond with ``\fIdk0\fP''.
 See section 6.1 and appendix C if the system does not reboot properly.
 .PP
 See section 6.1 and appendix C if the system does not reboot properly.
 .PP
-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.
+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.
 .NH 3
 Step 6: placing labels on the disks
 .PP
 .NH 3
 Step 6: placing labels on the disks
 .PP
-4.3BSD uses disk labels in the first sector of each disk to contain
+\*(4B 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 \fIdisklabel\fP\|(8).
 Note that recent CCI releases, and apparently Harris releases,
 information about the geometry of the drive and the partition layout.
 This information is written with \fIdisklabel\fP\|(8).
 Note that recent CCI releases, and apparently Harris releases,
@@ -400,36 +401,39 @@ skip this step if your machine is using disk labels already.
 Recent firmware for the console processor (CP) may use these labels,
 and thus the labels must be retained.
 Eventually, it will be possible to use both formats simultaneously.
 Recent firmware for the console processor (CP) may use these labels,
 and thus the labels must be retained.
 Eventually, it will be possible to use both formats simultaneously.
+You may wish to experiment on a spare disk once the system is running.
 .PP
 For each disk that you wish to label, run the following command:
 .DS
 .PP
 For each disk that you wish to label, run the following command:
 .DS
-\fB#\|\fPdisklabel -w dk\fIx\fP \fItype\fP "\fIoptional_pack_name\fP"
+\fB#\|\fP\fIdisklabel  -rw  dk\fP\fB#\fP  \fBtype\fP  \fI"optional_pack_name"\fP
 .DE
 .DE
-The \fItype\fP is the CCI disk device name as listed in section 1.3,
-or any other name listed in /etc/disktab.
+The \fB#\fP is the unit number; the \fBtype\fP is the CCI disk device
+name as listed in section 1.4 or any other name listed in /etc/disktab.
 The optional information may contain any descriptive name for the
 The optional information may contain any descriptive name for the
-contents of a disk, and may be up to 16 characters long.
-This procedure will place the label on the disk using the information
-found in /etc/disktab for the disk type named.
-The default disk partitions in \*(4B are the mostly
-the same as those in the CCI 1.21 release,
-except for CDC 340Mb xfd drives;
-see section 4.3.2 for details.
-If you have changed the disk partition sizes,
-you may add entries for the modified configuration in /etc/disktab
+contents of a disk, and may be up to 16 characters long.  This procedure
+will place the label on the disk using the information found in /etc/disktab
+for the disk type named.  The default disk partitions in \*(4B are the mostly
+the same as those in the CCI 1.21 release, except for CDC 340Mb xfd drives;
+see section 4.2 for details.  If you have changed the disk partition sizes,
+you may wish to add entries for the modified configuration in /etc/disktab
 before labeling the affected disks.
 before labeling the affected disks.
+.PP
+Note that the partition sizes and sectors per track in /etc/disktab
+are now specified in sectors, not units of kilobytes as in the vendors'
+4.2BSD and System V systems.
+For SMD disks, the sector size is 512 bytes, and is listed explicitly.
 .NH 3
 Step 7: setting up the /usr file system
 .PP
 The next thing to do is to extract the rest of the data from
 the tape.
 .NH 3
 Step 7: setting up the /usr file system
 .PP
 The next thing to do is to extract the rest of the data from
 the tape.
-You might wish to review the disk configuration information in section 4.4
-before continuing; the partitions used below are those most appropriate
+You might wish to review the disk configuration information in section
+4.2 before continuing; the partitions used below are those most appropriate
 in size.
 .PP
 For the Cypher tape drive, execute the following commands:
 .DS
 in size.
 .PP
 For the Cypher tape drive, execute the following commands:
 .DS
-\fB#\fP cd /dev; MAKEDEV cy0; sync
+\fB#\fP \fIcd /dev; MAKEDEV cy0\fP
 .DE
 Then perform the following:
 .br
 .DE
 Then perform the following:
 .br
@@ -438,61 +442,65 @@ Then perform the following:
 .DS
 .TS
 lw(2i) l.
 .DS
 .TS
 lw(2i) l.
-\fB#\fP date \fIyymmddhhmm\fP  (set date, see \fIdate\fP\|(1))
+\fB#\fP \fIdate yymmddhhmm\fP  (set date, see \fIdate\fP\|(1))
 \&....
 \&....
-\fB#\fP passwd root    (set password for super-user)
+\fB#\fP \fIpasswd root\fP      (set password for super-user)
 \fBNew password:\fP    (password will not echo)
 \fBRetype new password:\fP
 \fBNew password:\fP    (password will not echo)
 \fBRetype new password:\fP
-\fB#\fP hostname \fImysitename\fP      (set your hostname)
-\fB#\fP newfs dk0c     (create empty user file system)
-(this takes a few minutes)
-\fB#\fP mount /dev/dk0c /usr   (mount the usr file system)
-\fB#\fP cd /usr        (make /usr the current directory)
-\fB#\fP mt fsf
-\fB#\fP tar xpbf 20 /dev/rmt12         (extract all of usr except usr/src)
+\fB#\fP \fIhostname mysitename\fP      (set your hostname)
+\fB#\fP \fInewfs dk#c\fP       (create empty user file system)
+(\fIdk\fP is the disk type, \fI#\fP is the unit number, \fIc\fP
+is the partition; this takes a few minutes)
+\fB#\fP \fImount /dev/dk#c /usr\fP     (mount the usr file system)
+\fB#\fP \fIcd /usr\fP  (make /usr the current directory)
+\fB#\fP \fImt fsf\fP   (space to end of previous tape file)
+\fB#\fP \fItar xpf /dev/rmt12\fP       (extract all of usr except usr/src)
 (this takes about 15-20 minutes)
 .TE
 .DE
 (this takes about 15-20 minutes)
 .TE
 .DE
+If no disk label has been installed on the disk, the \fInewfs\fP
+command will require a third argument to specify the disk type,
+using one of the names in /etc/disktab.
 If the tape had been rewound or positioned incorrectly before the \fItar\fP,
 it may be repositioned by the following commands.
 .DS
 If the tape had been rewound or positioned incorrectly before the \fItar\fP,
 it may be repositioned by the following commands.
 .DS
-\fB#\fP mt rew
-\fB#\fP mt fsf 3
+\fB#\fP \fImt rew\fP
+\fB#\fP \fImt fsf 3\fP
 .DE
 The data on the fourth tape file has now been extracted.
 If you are using 1600bpi tapes,
 the first reel of the distribution is no longer needed;
 the remainder of the installation procedure uses the second
 .DE
 The data on the fourth tape file has now been extracted.
 If you are using 1600bpi tapes,
 the first reel of the distribution 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.
+reel of tape which should now be mounted in place of the first.
 The first instruction below should be ignored if using 1600bpi tapes.
 The installation procedure continues from this point on the 6250bpi tape.
 .DS
 .TS
 lw(2i) l.
 The first instruction below should be ignored if using 1600bpi tapes.
 The installation procedure continues from this point on the 6250bpi tape.
 .DS
 .TS
 lw(2i) l.
-\fB#\fP mt fsf         (do not do on 1600bpi tapes)
-\fB#\fP mkdir src      (make directory for source)
-\fB#\fP mkdir src/sys  (make directory for system source)
-\fB#\fP cd src/sys     (make /usr/sys the current directory)
-\fB#\fP tar xpbf 20 /dev/rmt12         (extract the system source)
+\fB#\fP \fImt fsf\fP           (6250bpi tapes only)
+\fB#\fP \fImkdir src\fP        (make directory for source)
+\fB#\fP \fImkdir src/sys\fP    (make directory for system source)
+\fB#\fP \fIcd src/sys\fP       (make /usr/src/sys the current directory)
+\fB#\fP \fItar xpbf 20 /dev/rmt12\fP   (extract the system source)
 (this takes about 5-10 minutes)
 (this takes about 5-10 minutes)
-\fB#\fP cd /   (back to root)
-\fB#\fP chmod 755  /  /usr  /usr/src /usr/src/sys
-\fB#\fP rm \-f sys
-\fB#\fP ln \-s usr/src/sys sys (make a symbolic link to the system source)
-\fB#\fP umount /dev/dk0c       (unmount /usr)
+\fB#\fP \fIcd /\fP     (back to root)
+\fB#\fP \fIchmod 755  /  /usr  /usr/src /usr/src/sys\fP
+\fB#\fP \fIrm \-f sys\fP
+\fB#\fP \fIln \-s usr/src/sys sys\fP   (make a symbolic link to the system source)
+\fB#\fP \fIumount /dev/dk#c\fP (unmount /usr)
 .TE
 .DE
 .PP
 You can check the consistency of the /usr file system by doing
 .DS
 .TE
 .DE
 .PP
 You can check the consistency of the /usr file system by doing
 .DS
-\fB#\fP fsck /dev/rdk0c
+\fB#\fP \fIfsck /dev/rdk#c\fP
 .DE
 The output from
 .I fsck
 should look something like:
 .DS
 .B
 .DE
 The output from
 .I fsck
 should look something like:
 .DS
 .B
-** /dev/rdk0c
+** /dev/rdk#c
 ** Last Mounted on /usr
 ** Phase 1 - Check Blocks and Sizes
 ** Phase 2 - Check Pathnames
 ** Last Mounted on /usr
 ** Phase 1 - Check Blocks and Sizes
 ** Phase 2 - Check Pathnames
@@ -504,20 +512,18 @@ should look something like:
 .DE
 .PP
 If there are inconsistencies in the file system, you may be prompted
 .DE
 .PP
 If there are inconsistencies in the file system, you may be prompted
-to apply corrective action; see the document describing
-.I fsck
-for information.
+to apply corrective action; see the \fIfsck\fP(8) or \fIFsck -- The UNIX
+File System Check Program\fP for more details.
 .PP
 .PP
-To use the /usr file system, you should now remount it by
-saying
+To use the /usr file system, you should now remount it with:
 .DS
 .DS
-\fB#\fP /etc/mount /dev/dk0c /usr
+\fB#\fP \fI/etc/mount /dev/dk#c /usr\fP
 .DE
 You can then extract the source code for the commands:
 .DS
 .DE
 You can then extract the source code for the commands:
 .DS
-\fB#\fP cd /usr/src
-\fB#\fP mt fsf
-\fB#\fP tar xpb 20
+\fB#\fP \fIcd /usr/src\fP
+\fB#\fP \fImt fsf\fP
+\fB#\fP \fItar xpb 20\fP
 .DE
 If you get an error at this point, most likely it was
 a problem with tape positioning.
 .DE
 If you get an error at this point, most likely it was
 a problem with tape positioning.
@@ -526,42 +532,46 @@ then skipping over the files already read (see \fImt\fP\|(1)).
 .NH 3
 Additional software
 .PP
 .NH 3
 Additional software
 .PP
-There are three extra tape files on the distribution tape(s)
-which have not been installed to this point.  They are
-a font library for use with Varian and Versatec printers,
-the Ingres database system, and user contributed software.
-All three tape files are in \fItar\fP\|(1) format and
-can be installed by positioning the tape 
+There is one additional tape file on the distribution tape(s)
+which has not been installed to this point;
+it contains user contributed software in \fItar\fP\|(1) format.
+On the 1600bpi tape set, this file is the sole file on the third tape.
+It can be installed by positioning the tape 
 using \fImt\fP\|(1) and reading
 using \fImt\fP\|(1) and reading
-in the files as was done for /usr/src above.  As distributed,
-the fonts should be placed in a directory /usr/lib/vfont, the
-Ingres system should be placed in /usr/ingres, and the user
-contributed software should be placed in /usr/src/new.  The
-exact contents of the user contributed software is given in
-a separate document.
+in the files as was done for /usr/src above.
+As distributed, the user contributed software should be placed in /usr/src/new.
+It may be extracted by mounting the appropriate tape (if not already mounted),
+positioning the tape at the beginning of this file (for 6250bpi),
+and extracting with
+.IR tar :
+.DS
+\fB#\fP \fIcd /usr/src\fP
+\fB#\fP \fImkdir new\fP
+\fB#\fP \fIchmod 755 new\fP
+\fB#\fP \fIcd new\fP
+\fB#\fP \fItar xpb 20\fP
+.DE
+Several of the directories for large contributed software subsystems
+have been placed in a single archive file and compressed to allow
 .NH 2
 Additional conversion information
 .PP
 .NH 2
 Additional conversion information
 .PP
-After setting up the new \*(4B filesystems,
-you may restore the user files that were saved on tape before beginning
-the conversion.
-Note that the \*(4B \fIrestore\fP program does
-its work on a mounted file system using normal system operations
-(unlike the older \fIrestor\fP 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 characteristics of the file system changed.  To restore
-a dump tape for, say, the /a file system something like the following
-would be used:
+After setting up the new \*(4B filesystems, you may restore the user
+files that were saved on tape before beginning the conversion.
+Note that the \*(4B \fIrestore\fP program does its work on a mounted
+file system using normal system operations.  This means that file
+system dumps may be restored even if the characteristics of the file
+system changed.  To restore a dump tape for, say, the /a file system
+something like the following would be used:
 .DS
 .DS
-\fB#\fP mkdir /a
-\fB#\fP newfs dk1c eagle
-\fB#\fP mount /dev/dk1c /a
-\fB#\fP cd /a
-\fB#\fP restore x
+\fB#\fP \fImkdir /a\fP
+\fB#\fP \fInewfs dk#c\fI
+\fB#\fP \fImount /dev/dk#c /a\fP
+\fB#\fP \fIcd /a\fP
+\fB#\fP \fIrestore x\fP
 .DE
 .PP
 If \fItar\fP images were written instead of doing a dump, you should
 .DE
 .PP
 If \fItar\fP 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 \fIfsck\fP when the job is complete.
+be sure to use its `-p' option when reading the files back.  No matter
+how you restore a file system, be sure to unmount it and and check its
+integrity with \fIfsck\fP(8) when the job is complete.