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