![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to 1.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 01.setup / tahoe|
Return to 1.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 01.setup / tahoe |
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.