share/doc/smm/01.setup/1.t

   1 .\" Copyright (c) 1988, 1993 The Regents of the University of California.
   2 .\" All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. All advertising materials mentioning features or use of this software
  13 .\"    must display the following acknowledgement:
  14 .\"     This product includes software developed by the University of
  15 .\"     California, Berkeley and its contributors.
  16 .\" 4. Neither the name of the University nor the names of its contributors
  17 .\"    may be used to endorse or promote products derived from this software
  18 .\"    without specific prior written permission.
  19 .\"
  20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30 .\" SUCH DAMAGE.
  31 .\"
  32 .\"     @(#)1.t 8.1 (Berkeley) 7/27/93
  33 .\"
  34 .ds lq ``
  35 .ds rq ''
  36 .ds LH "Installing/Operating \*(4B
  37 .ds RH Introduction
  38 .ds CF \*(Dy
  39 .LP
  40 .bp
  41 .Sh 1 "Introduction"
  42 .PP
  43 This document explains how to install the \*(4B Berkeley
  44 version of UNIX on your system.
  45 The filesystem format is compatible with \*(Ps
  46 and it will only be necessary for you to do a full bootstrap
  47 procedure if you are installing the release on a new machine.
  48 The object file formats are completely different from the System
  49 V release, so the most straightforward procedure for upgrading
  50 a System V system is to do a full bootstrap.
  51 .PP
  52 The full bootstrap procedure
  53 is outlined in section 2; the process starts with copying a filesystem
  54 image onto a new disk.
  55 This filesystem is then booted and used to extract the remainder of the
  56 system binaries and sources from the archives on the tape(s).
  57 .PP
  58 The technique for upgrading a \*(Ps system is described
  59 in section 3 of this document.
  60 The upgrade procedure involves extracting system binaries
  61 onto new root and
  62 .Pn /usr
  63 filesystems and merging local
  64 configuration files into the new system.
  65 User filesystems may be upgraded in place.
  66 Most \*(Ps binaries may be used with \*(4B in the course
  67 of the conversion.
  68 It is desirable to recompile local sources after the conversion,
  69 as the new compiler (GCC) provides superior code optimization.
  70 Consult section 3.5 for a description of some of the differences
  71 between \*(Ps and \*(4B.
  72 .Sh 2 "Distribution format"
  73 .PP
  74 The distribution comes in two formats:
  75 .DS
  76 (3)\0\0 6250bpi 2400' 9-track magnetic tapes, or
  77 (1)\0\0 8mm Exabyte tape
  78 .DE
  79 .PP
  80 If you have the facilities, we \fBstrongly\fP recommend copying the
  81 magnetic tape(s) in the distribution kit to guard against disaster.
  82 The tapes contain \*(Bb-byte records.
  83 There are interspersed tape marks;
  84 end-of-tape is signaled by a double end-of-file.
  85 The first file on the tape is architecture dependent.
  86 Additional files on the tape(s)
  87 contain tape archive images of the system binaries and sources (see
  88 .Xr tar (1)\**).
  89 .FS
  90 References of the form \fIX\fP(Y) mean the entry named
  91 \fIX\fP in section Y of the ``UNIX Programmer's Manual''.
  92 .FE
  93 See the tape label for a description of the contents
  94 and format of each individual tape.
  95 .Sh 2 "UNIX device naming"
  96 .PP
  97 Device names have a different syntax depending on whether you are talking
  98 to the standalone system or a running UNIX kernel.
  99 The standalone system syntax is currently architecture dependent and is
 100 described in the various architecture specific sections as applicable.
 101 When not running standalone, devices are available via files in the
 102 .Pn /dev/
 103 directory.
 104 The file name typically encodes the device type, its logical unit and
 105 a partition within that unit.
 106 For example,
 107 .Pn /dev/sd2b
 108 refers to the second partition (``b'') of
 109 SCSI (``sd'') drive number ``2'', while
 110 .Pn /dev/rmt0
 111 refers to the raw (``r'') interface of 9-track tape (``mt'') unit ``0''.
 112 .PP
 113 The mapping of physical addressing information (e.g. controller, target)
 114 to a logical unit number is dependent on the system configuration.
 115 In all simple cases, where only a single controller is present, a drive
 116 with physical unit number 0 (e.g., as determined by its unit
 117 specification, either unit plug or other selection mechanism)
 118 will be called unit 0 in its UNIX file name.
 119 This is not, however, strictly
 120 necessary, since the system has a level of indirection in this naming.
 121 If there are multiple controllers, the disk unit numbers will normally
 122 be counted sequentially across controllers.  This can be taken
 123 advantage of to make the system less dependent on the interconnect
 124 topology, and to make reconfiguration after hardware failure easier.
 125 .PP
 126 Each UNIX physical disk is divided into at most 8 logical disk partitions,
 127 each of which may occupy any consecutive cylinder range on the physical
 128 device.  The cylinders occupied by the 8 partitions for each drive type
 129 are specified initially in the disk description file
 130 .Pn /etc/disktab
 131 (c.f.
 132 .Xr disktab (5)).
 133 The partition information and description of the
 134 drive geometry are written in one of the first sectors of each disk with the
 135 .Xr disklabel (8)
 136 program.  Each partition may be used for either a
 137 raw data area such as a paging area or to store a UNIX filesystem.
 138 It is conventional for the first partition on a disk to be used
 139 to store a root filesystem, from which UNIX may be bootstrapped.
 140 The second partition is traditionally used as a paging area, and the
 141 rest of the disk is divided into spaces for additional ``mounted
 142 filesystems'' by use of one or more additional partitions.
 143 .Sh 2 "UNIX devices: block and raw"
 144 .PP
 145 UNIX makes a distinction between ``block'' and ``raw'' (character)
 146 devices.  Each disk has a block device interface where
 147 the system makes the device byte addressable and you can write
 148 a single byte in the middle of the disk.  The system will read
 149 out the data from the disk sector, insert the byte you gave it
 150 and put the modified data back.  The disks with the names
 151 .Pn /dev/xx0[a-h] ,
 152 etc., are block devices.
 153 There are also raw devices available.
 154 These have names like
 155 .Pn /dev/rxx0[a-h] ,
 156 the ``r'' here standing for ``raw''.
 157 Raw devices bypass the buffer cache and use DMA directly to/from
 158 the program's I/O buffers;
 159 they are normally restricted to full-sector transfers.
 160 In the bootstrap procedures we
 161 will often suggest using the raw devices, because these tend
 162 to work faster.
 163 Raw devices are used when making new filesystems,
 164 when checking unmounted filesystems,
 165 or for copying quiescent filesystems.
 166 The block devices are used to mount filesystems.
 167 .PP
 168 You should be aware that it is sometimes important whether to use
 169 the character device (for efficiency) or not (because it would not
 170 work, e.g. to write a single byte in the middle of a sector).
 171 Do not change the instructions by using the wrong type of device
 172 indiscriminately.