173 lines
7.5 KiB
Perl
173 lines
7.5 KiB
Perl
.\" Copyright (c) 1988, 1993 The Regents of the University of California.
|
|
.\" All rights reserved.
|
|
.\"
|
|
.\" 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 CF \*(Dy
|
|
.LP
|
|
.bp
|
|
.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
|
|
(3)\0\0 6250bpi 2400' 9-track magnetic tapes, or
|
|
(1)\0\0 8mm Exabyte tape
|
|
.DE
|
|
.PP
|
|
If you have the facilities, we \fBstrongly\fP recommend copying the
|
|
magnetic tape(s) in the distribution kit to guard against disaster.
|
|
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)
|
|
contain tape archive images of the system binaries and sources (see
|
|
.Xr tar (1)\**).
|
|
.FS
|
|
References of the form \fIX\fP(Y) mean the entry named
|
|
\fIX\fP in section Y of the ``UNIX Programmer's Manual''.
|
|
.FE
|
|
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
|
|
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
|
|
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
|
|
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
|
|
.Pn /dev/xx0[a-h] ,
|
|
etc., are block devices.
|
|
There are also raw devices available.
|
|
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.
|
|
In the bootstrap procedures we
|
|
will often suggest using the raw devices, because these tend
|
|
to work faster.
|
|
Raw devices are used when making new filesystems,
|
|
when checking unmounted filesystems,
|
|
or for copying quiescent filesystems.
|
|
The block devices are used to mount filesystems.
|
|
.PP
|
|
You should be aware that it is sometimes important whether to use
|
|
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).
|
|
Do not change the instructions by using the wrong type of device
|
|
indiscriminately.
|