Return to 1.t CVS log

Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 01.setup / tahoe

Annotation of 43BSDReno/share/doc/smm/01.setup/tahoe/1.t, revision 1.1

1.1     ! root        1: .\" Copyright (c) 1988 The Regents of the University of California.
        !             2: .\" All rights reserved.
        !             3: .\"
        !             4: .\" Redistribution and use in source and binary forms are permitted
        !             5: .\" provided that the above copyright notice and this paragraph are
        !             6: .\" duplicated in all such forms and that any documentation,
        !             7: .\" advertising materials, and other materials related to such
        !             8: .\" distribution and use acknowledge that the software was developed
        !             9: .\" by the University of California, Berkeley.  The name of the
        !            10: .\" University may not be used to endorse or promote products derived
        !            11: .\" from this software without specific prior written permission.
        !            12: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
        !            13: .\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
        !            14: .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
        !            15: .\"
        !            16: .\"    @(#)1.t 1.4 (Berkeley) 3/7/89
        !            17: .\"
        !            18: .ds lq ``
        !            19: .ds rq ''
        !            20: .ds LH "Installing/Operating \*(4B
        !            21: .ds RH Introduction
        !            22: .ds CF \*(DY
        !            23: .LP
        !            24: .nr H1 1
        !            25: .bp
        !            26: .LG
        !            27: .B
        !            28: .ce
        !            29: 1. INTRODUCTION
        !            30: .sp 2
        !            31: .R
        !            32: .NL
        !            33: .PP
        !            34: This document explains how to install the Berkeley
        !            35: version of UNIX for the Tahoe on your system.  While this is the first
        !            36: release from Berkeley for the Tahoe, the version of
        !            37: .UX
        !            38: distributed by Computer Consoles Inc. (CCI) was derived from 4.2BSD.
        !            39: Consequently, the filesystem
        !            40: format is compatible and it will only be necessary for you to perform
        !            41: a full bootstrap procedure if you are installing the release on a new
        !            42: machine.
        !            43: The System V UNIX systems distributed by CCI, Unisys (Sperry) and Harris
        !            44: are also derived from 4.2BSD, but only the network and filesystem
        !            45: remain compatible with \*(4B.
        !            46: The object file formats are completely different in the System V
        !            47: releases.
        !            48: Thus, the most straightforward procedure for upgrading a System V
        !            49: system is to perform a full bootstrap.
        !            50: .PP
        !            51: The full bootstrap procedure
        !            52: is outlined in chapter 2; the process includes booting standalone
        !            53: utilities from tape to format a disk, if necessary, and then copying
        !            54: a small root filesystem image onto a swap area.  This filesystem is
        !            55: then booted and used to extract a dump of a standard root filesystem.
        !            56: Finally, that root filesystem is booted, and the remainder of the system
        !            57: binaries and sources are read from the archives on the tape(s).
        !            58: .PP
        !            59: The technique for upgrading a 4.2 or beta-release 4.3BSD system is described
        !            60: in chapter 3 of this document.
        !            61: As \*(4B is completely compatible with the beta release,
        !            62: and sufficiently compatible with the vendor-supplied 4.2BSD releases,
        !            63: the upgrade procedure involves extracting a new set of system binaries
        !            64: onto new root and /usr filesystems.
        !            65: The sources are then extracted, and local configuration files are merged
        !            66: into the new system.  User filesystems may be upgraded in place.
        !            67: All 4.3BSD-beta binaries may be used with \*(4B in the course
        !            68: of the conversion.
        !            69: It is desirable to recompile local sources after the conversion,
        !            70: as the compilers have had many fixes installed.
        !            71: However, due to significant incompatibilities between
        !            72: the vendor-derived versions of 4.2BSD and the Berkeley \*(4B release, many
        !            73: 4.2BSD binary images will not function properly.  For such programs it
        !            74: will be both necessary and desirable to recompile this software after
        !            75: the conversion.  Consult section 3 for a description of the differences
        !            76: between \*(4B and the previous vendor-supplied systems for the Tahoe.
        !            77: .NH 2
        !            78: Hardware supported
        !            79: .PP
        !            80: This distribution can be booted on a CCI Power 6/32, Harris HCX-7,
        !            81: Unisys (Sperry) 7000/40, or ICL Clan 7 with any disks supported on the VERSAbus
        !            82: disk controllers sold by these vendors (SMD/E or VDDC).
        !            83: The new CCI SMD/E controller with working scatter-gather I/O
        !            84: is supported as well.
        !            85: In particular, the following drives are supported:
        !            86: .DS
        !            87: .TS
        !            88: l l.
        !            89: FUJITSU 160M   CDC 9766 300M
        !            90: FUJITSU 330M   CDC 340M
        !            91: FUJITSU 2351 Eagle     CDC 515M
        !            92: Maxtor 340M
        !            93: .TE
        !            94: .DE
        !            95: .PP
        !            96: The only tape drives supported by this distribution are the
        !            97: ones attached to the Ciprico Tapemaster tape controller.
        !            98: .NH 2
        !            99: Distribution format
        !           100: .PP
        !           101: The distribution comes in two formats:
        !           102: .DS
        !           103: (3)\0\0 1600bpi  2400'  9-track magnetic tapes, or
        !           104: (1)\0\0 6250bpi  2400'  9-track magnetic tape
        !           105: .DE
        !           106: Installation from scratch on any machine requires a tape unit.  If your
        !           107: machine is currently running 4.2 or 4.3BSD-beta and has a network connection
        !           108: to a 4.2 or 4.3BSD machine with a tape drive, it is a simple matter to
        !           109: install the software from a remote tape drive.
        !           110: .PP
        !           111: If you have the facilities, we \fBstrongly\fP recommend copying the
        !           112: magnetic tape(s) in the distribution kit to guard against disaster.
        !           113: The tapes contain some 1024-byte records followed by many
        !           114: 10240-byte records.  There are interspersed tape marks;
        !           115: end-of-tape is signaled by a double end-of-file.  The first file
        !           116: on the tape is a very small file system containing
        !           117: preliminary bootstrapping programs.  This is followed by a binary image
        !           118: of an approximately 2 megabyte ``mini root'' file system.  Following
        !           119: the mini root file is a full dump of the root file system
        !           120: (see \fIdump\fP\|(8)*).
        !           121: .FS
        !           122: \ * References of the form \fIX\fP(Y) mean the entry named
        !           123: \fIX\fP in section Y of the
        !           124: .UX
        !           125: programmer's manual.
        !           126: .FE
        !           127: Additional files on the tape(s)
        !           128: contain tape archive images of the system binaries and sources (see
        !           129: \fItar\fP\|(1)).  See Appendix A for a description of the contents
        !           130: and format of the tape(s).
        !           131: One file contains software
        !           132: contributed by the user community; refer to the accompanying
        !           133: documentation for a description of its contents and an
        !           134: explanation of how it should be installed.
        !           135: .NH 2
        !           136: Hardware terminology
        !           137: .PP
        !           138: This section gives a short discussion of hardware terminology
        !           139: to help you get your bearings. 
        !           140: .PP
        !           141: The Power 6/32 (and most related machines being shipped) use a VERSAbus
        !           142: for all I/O peripherals.  The console processor used for bootstrap and
        !           143: diagnostic purposes is also located on the VERSAbus.  The device naming
        !           144: conventions described here apply to the console processor; under UNIX
        !           145: device naming is considerably simpler.
        !           146: .PP
        !           147: The VERSAbus is a 32-bit bus that supports devices which
        !           148: use 16-bit, 24-bit, or 32-bit addresses (or some combination).
        !           149: The type of each address placed on the VERSAbus is indicated
        !           150: by an accompanying \fIaddress modifier\fP.  In addition to the
        !           151: width of the
        !           152: address present on the bus, VERSAbus address modifiers
        !           153: may be used to indicate the privileges of the requesting
        !           154: program (.e.g the program is executing in supervisory mode).
        !           155: The 6/32's VERSAbus adapter accepts device requests with either
        !           156: 16, 24, or 32-bit address modifiers.
        !           157: 16-bit addresses are used to access control registers
        !           158: for VERSAbus devices.
        !           159: 24-bit addresses are used to access up to one megabyte of VERSAbus
        !           160: local memory or device shared memory
        !           161: as well as the first 15Mb of main memory.
        !           162: 24-bit addresses are used for DMA by some peripherals,
        !           163: interpreting the address
        !           164: as an absolute physical address in referencing main memory.
        !           165: Other devices use 32-bit addressing, allowing them to access all
        !           166: of main memory.
        !           167: This means that the address space for 24-bit devices overlaps
        !           168: that of 32-bit devices.
        !           169: Devices which do not support full 32-bit
        !           170: addressing can be difficult to work with as their limited addressing
        !           171: restricts the placement of I/O buffers in main memory.  Unfortunately,
        !           172: because the VERSAbus has had limited acceptance, there are
        !           173: very few good VERSAbus device controllers available; this has
        !           174: resulted in several non-VERSAbus devices being attached to the
        !           175: VERSAbus through bus-adapter cards.  Devices of this sort often
        !           176: support only 20-bit or 24-bit addressing.
        !           177: .PP
        !           178: From the Tahoe side of the VERSAbus adaptor,
        !           179: the three address spaces are mapped so as to avoid
        !           180: overlaps.  Physical addresses in the range 0xffff0000 to 0xfffffff are
        !           181: used to access VERSAbus devices which use 16-bit addresses.  References
        !           182: to this region of the Tahoe address space result in a VERSAbus
        !           183: transfer with a 16-bit address generated from the lower order 16
        !           184: bits of the memory address and a ``short addressing non-privileged I/O
        !           185: access'' address modifier (0x10).  Addresses in the range 0xff000000 to
        !           186: 0xffff0000 are used to access 24-bit VERSAbus devices, generating a 24-bit
        !           187: address and a ``standard addressing non-privileged data access''
        !           188: address modifier (0x01).
        !           189: Within this range, addresses from 0xfff00000 to 0xffff0000 refer
        !           190: to VERSAbus local memory used by devices (such as the VIOC)
        !           191: for shared communication areas.
        !           192: Finally, any other address in the
        !           193: the primary I/O adapter space, 0xc0000000 to 0xff000000, generates
        !           194: a 32-bit VERSAbus address with an ``extended addressing non-privileged
        !           195: data access'' address modifier (0xf1).  Note, however, that 32-bit
        !           196: addresses generated by references to this region result in a VERSAbus
        !           197: address with bits 31-30 set to 0.  Thus, for example, a reference to
        !           198: a device located at 0xfe000000 would result in a VERSAbus transfer
        !           199: with the address set to 0x3e000000.  A complete list of the characteristics
        !           200: of the devices supported in the system may be found in Appendix A.
        !           201: .PP
        !           202: The console processor has a set of names for devices:
        !           203: .DS
        !           204: .TS
        !           205: l l.
        !           206: FUJITSU 160M disk drives       fsd
        !           207: FUJITSU 330M disk drives       fuj
        !           208: FUJITSU 450M disk drives       egl**
        !           209: CDC 300M disk drives   smd
        !           210: CDC 340M disk drives   xfd
        !           211: CDC 515M disk drives   xsd
        !           212: MXD Maxtor 340M disk drives    mxd
        !           213: Cipher tape drives     cyp
        !           214: .TE
        !           215: .FS
        !           216: **\|Eagle drives are not supported by the console processor on all tahoe
        !           217: machines.
        !           218: .FE
        !           219: .DE
        !           220: Devices are fully specified to the console processor with:
        !           221: .DS
        !           222: xxx(y,z)
        !           223: .DE
        !           224: where \fIxxx\fP is one of the above names (e.g. \fIxfd\fP).
        !           225: The value \fIy\fP specifies a controller to use and also
        !           226: the device; it is computed as
        !           227: .DS
        !           228: 8 * \fIcontroller\fP + \fIdevice\fP
        !           229: .DE
        !           230: Thus, controller 0 (by convention the controller located at VERSAbus
        !           231: address 0xfff2400), drive 0 would have a \fIy\fP value of 0
        !           232: while controller 1 (address of 0xfff2800) drive 0 would have a \fIy\fP
        !           233: value of 4*.
        !           234: .FS
        !           235: *\|Note that this means you can not reference drives 4-15 on a
        !           236: controller; as a result we expect the console interface to
        !           237: change soon.
        !           238: .FE
        !           239: The \fIz\fP value is interpreted differently for tapes and disks;
        !           240: for disks it is a disk block, and for tapes it is a file number
        !           241: on the tape.
        !           242: .PP
        !           243: The console processor has the notion of a \fIdefault device\fP
        !           244: to use with file related commands.  The default device is specified
        !           245: according to the form shown above.  Further, the console processor,
        !           246: by default, interprets certain system files on the default disk to discover
        !           247: information about disk drives in the system.  As
        !           248: .UX
        !           249: device names are decidedly different from the names used by the
        !           250: console processor this can lead to serious confusion.  We will
        !           251: return to this problem later in section 4; for now you should
        !           252: simply be aware of the difference in naming conventions.
        !           253: .NH 2
        !           254: UNIX device naming
        !           255: .PP
        !           256: UNIX has a set of names for devices which are different
        !           257: from the CCI names for the devices, viz.:
        !           258: .DS
        !           259: .TS
        !           260: l l.
        !           261: VERSAbus disk drives   dk
        !           262: Cipher tape drives     cy
        !           263: .TE
        !           264: .DE
        !           265: .PP
        !           266: The standalone system, used to bootstrap the full UNIX system,
        !           267: uses device names of the form:
        !           268: .DS
        !           269: xx(c,d,p)
        !           270: .DE
        !           271: where \fIxx\fP is the device type, normally \fIdk\fP or \fIcy\fP.  The
        !           272: value \fIc\fP specifies the controller to use, and \fId\fP specifies
        !           273: the device.  The \fIp\fP value is interpreted differently for tapes
        !           274: and disks: for disks it is a disk \fIpartition\fP (in the range 0-7),
        !           275: and for tapes it is a file number offset on the tape.  Thus, partition
        !           276: 1 of a ``dk'' type disk drive on controller vd0 at drive 0 would be
        !           277: ``dk(0,0,1)''.  Normally the controller will be controller 0; it
        !           278: may therefore be omitted from the device specification, and most of
        !           279: the examples in this document reflect this.  When not running
        !           280: standalone, this partition would normally be available as ``/dev/dk0b''.
        !           281: Here the prefix ``/dev'' is the name of the directory where all
        !           282: ``special files'' normally live, the ``dk'' serves the obvious purpose,
        !           283: the ``0'' identifies this as a partition of dk drive number ``0'' and
        !           284: the ``b'' identifies this as the second partition.
        !           285: .PP
        !           286: In all simple cases, where only a single controller is present, a drive
        !           287: with unit number 0 (determined by its unit plug on the front of the drive)
        !           288: will be called unit 0 in its UNIX file name.  This is not, however, strictly
        !           289: necessary, since the system has a level of indirection in this naming.
        !           290: If there are multiple controllers, the disk unit numbers will normally
        !           291: be counted sequentially across controllers.  This can be taken
        !           292: advantage of to make the system less dependent on the interconnect
        !           293: topology, and to make reconfiguration after hardware failure extremely
        !           294: easy.
        !           295: .PP
        !           296: Each UNIX physical disk is divided into at most 8 logical disk partitions,
        !           297: each of which may occupy any consecutive cylinder range on the physical
        !           298: device.  The cylinders occupied by the 8 partitions for each drive type
        !           299: are specified initially in the disk description file /etc/disktab
        !           300: (c.f. \fIdisktab\fP(5)).  The partition information and description of the
        !           301: drive geometry are written in the first sector of each disk with the
        !           302: \fIdisklabel\|\fP(8) program.  Each partition may be used for either a
        !           303: raw data area such as a paging area or to store a UNIX file system.
        !           304: It is conventional for the first partition on a disk to be used
        !           305: to store a root file system, from which UNIX may be bootstrapped.
        !           306: The second partition is traditionally used as a paging area, and the
        !           307: rest of the disk is divided into spaces for additional ``mounted
        !           308: file systems'' by use of one or more additional partitions.
        !           309: .PP
        !           310: Returning to the discussion of the standalone system, we recall
        !           311: that tapes also took three integer parameters.  In the normal case
        !           312: where the Cipher tape drive is unit 0 on the first controller, the
        !           313: files on the tape have names ``cy(0, 0)'', ``cy(0, 1)'', etc.
        !           314: Here ``file'' means a tape file containing a single data stream.
        !           315: The distribution tape(s) have data structures in the tape
        !           316: files and though the tape(s) contain only 9 tape files, they contain
        !           317: several thousand UNIX files.
        !           318: .NH 2
        !           319: UNIX devices: block and raw
        !           320: .PP
        !           321: UNIX makes a distinction between ``block'' and ``raw'' (character)
        !           322: devices.  Each disk has a block device interface where
        !           323: the system makes the device byte addressable and you can write
        !           324: a single byte in the middle of the disk.  The system will read
        !           325: out the data from the disk sector, insert the byte you gave it
        !           326: and put the modified data back.  The disks with the names
        !           327: ``/dev/xx0[a-h]'', etc., are block devices.
        !           328: There are also raw devices available.
        !           329: These have names like ``/dev/rxx0[a-h]'', the
        !           330: ``r'' here standing for ``raw''.
        !           331: Raw devices bypass the buffer cache and use DMA directly to/from
        !           332: the program's I/O buffers;
        !           333: they are normally restricted to full-sector transfers.
        !           334: In the bootstrap procedures we
        !           335: will often suggest using the raw devices, because these tend
        !           336: to work faster.
        !           337: Raw devices are used when making new filesystems,
        !           338: when checking unmounted filesystems,
        !           339: or for copying quiescent filesystems.
        !           340: The block devices are used to mount file systems,
        !           341: or when operating on a mounted filesystem such as the root.
        !           342: .PP
        !           343: You should be aware that it is sometimes important whether to use
        !           344: the character device (for efficiency) or not (because it wouldn't
        !           345: work, e.g. to write a single byte in the middle of a sector).
        !           346: Don't change the instructions by using the wrong type of device
        !           347: indiscriminately.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.