minnie.tuhs.org

home *** CD-ROM | disk | FTP | other *** search

/ minnie.tuhs.org / unixen.tar / unixen / Documentation / PUPS / Setup / 2.9bsd_setup.txt < prev next >

Wrap

Text File | 2000-05-25 | 154.6 KB | 4,225 lines

IInnssttaalllliinngg aanndd OOppeerraattiinngg 22..99BBSSDD 1177 MMaarrcchh 11999988 _M_i_c_h_a_e_l _J_. _K_a_r_e_l_s _C_a_r_l _F_. _S_m_i_t_h University of California Berkeley, California 94720 _A_B_S_T_R_A_C_T This document contains instructions for installation and operation of the Second Berkeley Software Distribution's 2.9BSD release of the PDP-11|- UNIX|= system. It is adapted from the paper _I_n_s_t_a_l_l_i_n_g _a_n_d _O_p_e_r_a_t_i_n_g _4_._1_b_s_d by Bill Joy. This document explains the procedures for installation of Berkeley UNIX on a PDP-11 or to upgrade an existing Berkeley PDP-11 UNIX system to the new release. It then explains how to config- ure the kernel for the available devices and user load, lay out file systems on the available disks, set up terminal lines and user accounts, and do system specific tailoring. It also explains sys- tem operations procedures: shutdown and startup, hardware error reporting and diagnosis, file sys- tem backup procedures, resource control, perfor- mance monitoring, and procedures for recompiling and reinstalling system software. Technical details on the kernel changes are presented in the accompanying paper, ``Changes in the Kernel in 2.9BSD.'' The 2.9BSD release, unlike previous versions of the Second Berkeley Software Distribution, is a complete Version 7 UNIX system with all of the standard UNIX tools and utilities, with or without Berkeley modifications. Therefore, it does not need to be layered onto an existing Version 7 sys- tem; because of the many changes and additions throughout the system, it would require a substan- tial effort to merge into most earlier systems. ----------- |-DEC, MASSBUS, PDP, and UNIBUS are trademarks of Digital Equipment Corporation. |=UNIX is a trademark of Bell Laboratories. 17 March 1998 Installing/Operating 2.9BSD -2- Introduction 11.. IINNTTRROODDUUCCTTIIOONN This document explains how to install the 2.9BSD release of the Berkeley version of UNIX for the PDP-11 on your system. If you are running the July 1981 release of the system, which was called 2.8BSD, you can avoid a full bootstrap from the new tape by extracting only the software that has changed. Be warned, however, that there are a large number of changes. Unless you have many local modifi- cations it will probably be easier to bring up an intact 2.9BSD system and merge your local changes into it. If you are running any other version of UNIX on your PDP-11, you will have to do a full bootstrap. This means dumping all file systems which are to be retained onto tape in a format that can be read in again later (_t_a_r format is best, or V7 _d_u_m_p if the file system configuration will be the same). A new root file system can be made and read in using stan- dalone utilites on the tape. The system sources and the rest of the /usr file system can then be extracted. Finally, old file systems can be reloaded from tape. To get an overview of the process and an idea of some of the alternative strategies that are available, it is wise to look through all of these instructions before beginning. 00..11.. HHaarrddwwaarree ssuuppppoorrtteedd This distribution can be booted on a PDP-11/23, 24, 34, 34A, 40, 44, 45, 55, 60, or 70 CPU with at least 192 Kbytes of memory and any of the following disks|-: DEC MASSBUS: RM03, RM05, RP04, RP05, RP06 DEC UNIBUS: RK05, RK06, RK07, RL01, RL02, RM02, RP03, RP04, RP05, RP06 AED 8000 UNIBUS: AMPEX DM980 (emulating RP03) AED STORM-II AMPEX DM980 (emulating RM02) DIVA COMP V MASSBUS: AMPEX 9300 EMULEX SC-21 UNIBUS: AMPEX 9300, CDC 9766 (emulating RM05) EMULEX SC-11 or SC-21 UNIBUS: CDC 9762, AMPEX DM980 The tape drives|- supported by this distribution are: DEC MASSBUS: TE16, TU45, TU77 DEC UNIBUS: TE10, TE16, TS11, TU45, TU77 DATUM 15X20 UNIBUS: KENNEDY 9100 (emulating TE10) EMULEX TC-11 UNIBUS: KENNEDY 9100, 9300 (emulating TE10) 17 March 1998 Installing/Operating 2.9BSD -3- Introduction 00..22.. DDiissttrriibbuuttiioonn ffoorrmmaatt The distribution format is two 9-track 800bpi 2400' magnetic tapes. The tapes are also available at 1600bpi. The format for 1600bpi tapes is the same. If you are able to do so, it is a good idea to immediately copy the tapes in the distribution kit to guard against disaster. The first tape contains some 512-byte records, some 1024-byte records, followed by many 10240-byte records. There are interspersed tape marks; end-of-tape is signaled by a double end-of-file. The second tape contains only 10240-byte records with no interspersed tape marks. The boot tape contains several standalone utility pro- grams, a _d_u_m_p image of a root file system, and a _t_a_r image of part of the /usr file system. The files on this tape are: ----------- |- Other controllers and drives may be easily usable with the system, but might require minor modifications to the system to allow bootstrap- ping. The controllers and the drives shown here are known to work as bootstrap devices. 17 March 1998 Installing/Operating 2.9BSD -4- Introduction File Contents Record Size 0 boot block 512 (EOR) boot block 512 (EOR) Standalone BBoooott 512 (EOF) 1 Standalone ccaatt 1024 (EOF) 2 This index 1024 (use ccaatt to read) (EOF) 3 Standalone mmkkffss 1024 (see _m_k_f_s(8)|-) (EOF) 4 Standalone rreessttoorr 1024 (see _r_e_s_t_o_r(8)) (EOF) 5 Standalone iicchheecckk 1024 (see _i_c_h_e_c_k(8)) (EOF) 6 Dump of small ``root'' file system 10240 (213 10K-byte blocks; see _d_u_m_p(8)) (EOF) 7 Tar archive of /usr files 10240 (most of the tape; see _t_a_r(1)) (EOF) (EOF) The last file on the tape is a _t_a_r image of most of the /usr file system except for sources (relative to /usr; see _t_a_r(1)). It contains most of the binaries and other mate- rial which is normally kept on-line, with the following directories: 7700 aaddmm bbiinn ccoonnttrriibb ddiicctt ddoocc ggaammeess iinncclluuddee lliibb llooccaall mmaann mmssggss pprreesseerrvvee ppuubblliicc ssppooooll ssyyss ttmmpp uuccbb. It con- tains 1594 10K byte blocks. The second tape contains one file in _t_a_r format, again relative to /usr, consisting of 1958 10K byte blocks and containing the source tree with all command and kernel sources. It contains the directories nneett, ssrrcc, and iinnggrreess and includes the Berkeley additions (which are in /usr/src/ucb and /usr/ingres). The nneett direc- tory contains sources for the TCP/IP system. 00..33.. UUNNIIXX ddeevviiccee nnaammiinngg UNIX has a set of names for devices that are different from the DEC names for the devices. The disk and tape names used by the bootstrap and the system are: ----------- |-References of the form _X(_Y) mean the subsection named _X in section _Y of the Berkeley PDP-11 UNIX Programmer's manual. 17 March 1998 Installing/Operating 2.9BSD -5- Introduction RK05 disks rrkk RK06, RK07 disks hhkk RL01, RL02 disks rrll RP02, RP03 disks rrpp TE16, TU45, TU77/TM02, 3 tapes hhtt TE10/TM11 tapes ttmm TS11 tapes ttss There is also a generic disk driver, xxpp, that will han- dle most types of SMD disks on one or more controllers (even different types on the same controller). The xxpp driver han- dles RM02, RM03, RM05, RP04, RP05 and RP06 disks on DEC, Emulex, and Diva UNIBUS or MASSBUS controllers. The standalone system used to bootstrap the full UNIX system uses device names of the form: _x_x(_y,_z) where _x_x is one of hhkk, hhtt, rrkk, rrll, rrpp, ttmm, ttss, or xxpp. The value _y specifies the device or drive unit to use. The _z value is interpreted differently for tapes and disks: for disks it is a block offset for a file system and for tapes it is a file number on the tape. Large UNIX physical disks (hhkk, rrpp, xxpp) are divided into 8 logical disk partitions, each of which may occupy any con- secutive cylinder range on the physical device. The cylin- ders occupied by the 8 partitions for each drive type are specified in section 4 of the Berkeley PDP-11 UNIX Program- mer's manual.|- Each partition may be used for either a raw data area such as a swapping area or to store a UNIX file system. It is conventional for the first partition on a disk to be used to store a root file system, from which UNIX may be bootstrapped. The second partition is traditionally used as a swapping area, and the rest of the disk is divided into spaces for additional ``mounted file systems'' by use of one or more additional partitions. The disk partitions have names in the standalone system of the form ``_x_x(_y,_z)'' as described above. Thus partition 1 of an RK07 at drive 0 would be ``hk(0,5940)''. When not running standalone, this partition would normally be avail- able as ``/dev/hk0b''. Here the prefix ``/dev'' is the name of the directory where all ``special files'' normally live, the ``hk'' serves an obvious purpose, the ``0'' identifies this as a partition of hk drive number ``0'' and the ``b'' identifies this as partition 1 (where we number from 0, the ----------- |-It is possible to change the partitions by chang- ing the values in the disk's sizes array in ioconf.c. 17 March 1998 Installing/Operating 2.9BSD -6- Introduction 0th partition being ``hk0a''). Finally, ``5940'' is the sector offset to partition 1, as determined from the manual page _h_k(4). Returning to the discussion of the standalone system, we recall that tapes also took two integer parameters. In the case of a TE16/TU tape formatter on drive 0, the files on the tape have names ``ht(0,0)'', ``ht(0,1)'', etc. Here ``file'' means a tape file containing a single data stream separated by a single tape mark. The distribution tapes have data structures in the tape files and though the first tape contains only 8 tape files, it contains several thou- sand UNIX files. 00..44.. UUNNIIXX ddeevviicceess:: bblloocckk aanndd rraaww UNIX makes a distinction between ``block'' and ``char- acter'' (raw) devices. Each disk has a block device inter- face 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 ``/dev/_x_x0a'', etc. are block devices and thus use the system's normal buffering mechanism. There are also raw devices available, which do physical I/O opera- tions directly from the program's data area. These have names like ``/dev/r_x_x0a'', the ``r'' here standing for ``raw.'' In the bootstrap procedures we will often suggest using the raw devices, because these tend to work faster. In general, however, the block devices are used. They are where file systems are ``mounted.'' The UNIX name space is increased by logically associating (_m_o_u_n_ting) a UNIX file system residing on a given block device with a directory in the current name space. See _m_o_u_n_t(2) and _m_o_u_n_t(8). This association is severed by _u_m_o_u_n_t. You should be aware that it is sometimes important to use the character device (for efficiency) or not (because it wouldn't work, e.g. to write a single byte in the middle of a sector). Don't change the instructions by using the wrong type of device indiscriminately. 00..55.. RReeppoorrttiinngg pprroobblleemmss oorr qquueessttiioonnss Problems with the software of this distribution, or errors or omissions in the documentation, should be reported to the 2BSD group. Whenever possible, submit such reports by electronic mail; the address is: 2bsd@berkeley (by ARPAnet) or ucbvax!2bsd (by UUCP) There is a mail drop for bug reports and fixes: 17 March 1998 Installing/Operating 2.9BSD -7- Introduction 2bsd-bugs@berkeley (by ARPAnet) or ucbvax!2bsd-bugs (by UUCP) These reports or fixes are expected to be in the format gen- erated by the _s_e_n_d_b_u_g(1) program. A redistribution list of users who have indicated that they would like to receive bug reports is also maintained: 2bsd-people@berkeley(by ARPAnet) or ucbvax!2bsd-people (by UUCP) This list may also be used as a general forum for help requests, sharing common experiences, etc. Requests to be added to (or deleted from) this list should be made to the 2bsd address above. If it is not possible to use electronic mail, then call or write the 2BSD office. Although there is seldom someone there to take your call, there is an answer- ing machine, and your request will be forwarded to the appropriate person. The phone number and mailing address are: Berkeley PDP-11 Software Distribution - 2BSD Computer Science Division, Department of EECS 573 Evans Hall University of California, Berkeley Berkeley, California 94720 (415) 642-6258 17 March 1998 Installing/Operating 2.9BSD -8- Bootstrapping 22.. BBOOOOTTSSTTRRAAPP PPRROOCCEEDDUURREESS This section explains the bootstrap procedures that can be used to get one of the kernels supplied with this tape running on your machine. If you are not yet running UNIX or are running a version of UNIX other than 2.8BSD, you will have to do a full bootstrap. If you are running 2.8BSD you can use the update proce- dure described in section 4.2 instead of a full bootstrap. This will affect modifications to the local system less than a full bootstrap. Note, however, that a full bootstrap will probably require less effort unless you have made major local modifications which you must carry over to the new system. If you are already running UNIX and need to do a full bootstrap you should first save your existing files on mag- netic tape. The 2.9BSD file system uses 1K-byte blocks by clustering disk blocks (as did the 2.8BSD system); file sys- tems in other formats cannot be mounted. TThhoossee uuppggrraaddiinngg ffrroomm 22..88 sshhoouulldd nnoottee tthhaatt 22..99BBSSDD uusseess ggeenneerraallllyy ddiiffffeerreenntt ffiillee ssyysstteemm ppaarrttiittiioonn ssiizzeess tthhaann 22..88BBSSDD,, aanndd tthhaatt aa ffeeww ooff tthhee mmaajjoorr ddeevviiccee nnuummbbeerrss hhaavvee cchhaannggeedd ((iinn ppaarrttiiccuullaarr,, tthhaatt ffoorr tthhee hhkk)).. The easiest way to save the current files on tape is by doing a full dump and then restoring in the new system. This works also in converting V7, System-III, or System-V 512-byte file systems. Although the dump format is different on V7, System-III, and System-V, _5_1_2_r_e_s_t_o_r(8) can restore old format V7 _d_u_m_p image tapes into the file system format used by 2.9BSD. _T_a_r(1) can also be used to exchange files from different file system formats, and has the addi- tional advantage that directory trees can be placed on dif- ferent file systems than on the old configuration. Note that 2.9BSD does not support _c_p_i_o tape format. The tape bootstrap procedure involves three steps: loading the tape bootstrap monitor, creating and initializ- ing a UNIX ``root'' file system system on the disk, and booting the system. 22..11.. BBoooottiinngg ffrroomm ttaappee To load the tape bootstrap monitor, first mount the magnetic tape on drive 0 at load point, making sure that the write ring is not inserted. Then use the normal bootstrap ROM, console monitor or other bootstrap to boot from the tape. If no other means are available, the following code can be keyed in and executed at (say) 0100000 to boot from a TM tape drive (the magic number 172526 is the address of the TM-11 current memory address register; an adjustment may be necessary if your controller is at a nonstandard address): 17 March 1998 Installing/Operating 2.9BSD -9- Bootstrapping 012700 (mov $172526, r0) 172526 010040 (mov r0, -(r0)) 012740 (mov $60003, -(r0)) 060003 000777 (br .) When this is executed, the first block of the tape will be read into memory. Halt the CPU and restart at location 0. The console should type _n_nBBoooott :: where _n_n is the CPU class on which it believes it is run- ning. The value will be one of 24, 40, 45 or 70, depending on whether separate instruction and data (separate I/D) and/or a UNIBUS map are detected. The CPUs in each class are: Class PDP11s Separate I/D UNIBUS map 24 24 - + 40 23, 34, 34A, 40, 60 - - 45 45, 55 + - 70 44, 70 + + The bootstrap can be forced to set up the machine as for a different class of PDP11 by placing an appropriate value in the console switch register (if there is one) while booting it. The value to use is the PDP11 class, interpreted as an _o_c_t_a_l number (use, for example, 070 for an 11/70). WWaarrnniinngg:: some old DEC bootstraps use the switch register to indicate where to boot from. On such machines, if the value in the switch register indicates an incorrect CPU, be sure to reset the switches immediately after initiating the tape boot- strap. You are now talking to the tape bootstrap monitor. At any point in the following procedure you can return to this section, reload the tape bootstrap, and restart. To first check that everything is working properly, you can use the _c_a_t program on the tape to print the list of utilities on the tape. Through the rest of this section, substitute the correct disk type for _d_k and the tape type for _t_p. In response to the prompt of the bootstrap which is now running, type _t_p(0,1) (load file 1 from tape 0) 17 March 1998 Installing/Operating 2.9BSD -10- Bootstrapping _C_a_t will respond CCaatt FFiillee?? The table of contents is in file 2 on the tape, therefore answer _t_p(0,2) The tape will move, then a short list of files will print on the console, followed by: eexxiitt ccaalllleedd _n_nBBoooott :: After _c_a_t is finished, it returns to the bootstrap for the next operation. 22..22.. CCrreeaattiinngg aann eemmppttyy UUNNIIXX ffiillee ssyysstteemm Now create the root file system using the following procedures. First determine the size of your root file sys- tem from the following table: Disk Root File System Size (1K-byte blocks) hk 2970 rk|- 2000 rl01|- 4000 rl02|- 8500 rp 5200 xp 4807 (RP04/RP05/RP06) 2400 (RM02/RM03) 4560 (RM05) 4702 (DIVA) If the disk on which you are creating a root file sys- tem is an xxpp disk, you should check the drive type register at this time to make sure it holds a value that will be rec- ognized correctly by the driver. There are numbering con- flicts; the following numbers are used internally: ----------- |-These sizes are for full disks less some space used for swapping. 17 March 1998 Installing/Operating 2.9BSD -11- Bootstrapping Drive Type Register Drive Assumed Low Byte (standard address: 0776726) 022 RP04/05/06 025 RM02/RM03 027 RM05 076 Emulex SC-21/300 Mb RM05 emulation (815 cylinders) 077 Diva Comp-V/300 Mb SMD Check the drive type number in your controller manual, or halt the CPU and examine this register. If the value does not correspond to the actual drive type, you must place the correct value in the switch register after the tape boot- strap is running and before any attempt is made to access the drive. This will override the drive type register. This value must be present at the time each program (includ- ing the bootstrap itself) first tries to access the disk. On machines without a switch register, the _x_p_t_y_p_e variable can be patched in memory. After starting each utility but before accessing the disk, halt the CPU, place the new drive type number at the proper memory location with the console switches or monitor, and then continue. The location of _x_p_t_y_p_e in each utility is mkfs: 032700, restor: 031570, icheck: 030150 and boot: 0427754 (the location for boot is higher because it relocates itself). Once UNIX itself is booted (see below) you must patch it also. Finally, determine the proper interleaving factors _m and _n for your disk and CPU combination from the following table. These numbers determine the layout of the free list that will be constructed; the proper interleaving will help increase the speed of the file system. If you have a non- DEC disk that emulates one of the disks listed, you may be able to use these numbers as well, but check that the actual disk geometry is the same as the emulated disk (rather than the controller mapping onto a different physical disk). Also, the rotational speed must be the same as the DEC disk for these numbers to apply. 17 March 1998 Installing/Operating 2.9BSD -12- Bootstrapping DDiisskk IInntteerrlleeaavviinngg FFaaccttoorrss ffoorr DDiisskk//CCPPUU CCoommbbiinnaattiioonnss ((_m//_n)) CPU RK05 RK06/7 RL01/2 RM02 RM03 RM05 RP03 RP04/5/6 11/23 X/12 X/33 X/10 X/80 - - X/100 X/209 11/24 X/12 7/33 X/10 10/80 - - X/100 10/209 11/34 X/12 6/33 X/10 8/80 - - 3/100 8/209 11/40 2/12 6/33 X/10 8/80 - - 3/100 8/209 11/44 X/12 4/33 X/10 6/80 - - 2/100 6/209 11/45 2/12 5/33 X/10 7/80 - - 3/100 7/209 11/55 X/12 5/33 X/10 7/80 - - 3/100 7/209 11/60 X/12 5/33 X/10 7/80 - - 3/100 7/209 11/70 X/12 3/33 X/10 5/80 7/80 7/304 X/100 5/209 For example, for an RP06 on an 11/70, _m is 5 and _n is 209. See _m_k_f_s(8) for more explanation of the values of _m and _n. An X entry means that we do not know the correct number for this combination of CPU and disk. If you do, please let us know. If _m is unspecified or you have a disk which emulates a DEC disk, use the number for the most similar disk/CPU pair. IIff _n iiss uunnssppeecciiffiieedd,, uussee tthhee ccyylliinnddeerr ssiizzee ddiivviiddeedd bbyy 22.. Then run a standalone version of the _m_k_f_s (8) program. In the following procedure, substitute the correct types for _t_p and _d_k and the size determined above for _s_i_z_e: ::_t_p(0,3) MMkkffss ffiillee ssyysstteemm:: _d_k(0,0) (root is the first file system on drive 0) ffiillee ssyysstteemm ssiizzee:: _s_i_z_e (count of 1024 byte blocks in root) iinntteerrlleeaavviinngg ffaaccttoorr ((mm,, 55 ddeeffaauulltt)):: _m (interleaving, see above) iinntteerrlleeaavviinngg mmoodduulluuss ((nn,, 1100 ddeeffaauulltt)):: _n (interleaving, see above) iissiizzee == XXXX (count of inodes in root file system) mm//nn == _m _n (interleave parameters) EExxiitt ccaalllleedd _n_nBBoooott :: (back at tape boot level) You now have an empty UNIX root file system. 22..33.. RReessttoorriinngg tthhee rroooott ffiillee ssyysstteemm To restore a small root file system onto it, type 17 March 1998 Installing/Operating 2.9BSD -13- Bootstrapping ::_t_p(0,4) RReessttoorr TTaappee?? _t_p(0,6) (unit 0, seventh tape file) DDiisskk?? _d_k(0,0) (into root file system) LLaasstt cchhaannccee bbeeffoorree ssccrriibbbblliinngg oonn ddiisskk.. (just hit return) (30 second pause then tape should move) (tape moves for a few minutes) eenndd ooff ttaappee EExxiitt ccaalllleedd _n_nBBoooott :: (back at tape boot level) If you wish, you may use the _i_c_h_e_c_k program on the tape, _t_p(0,5), to check the consistency of the file system you have just installed. 22..44.. BBoooottiinngg UUNNIIXX You are now ready to boot from disk. It is best to read the rest of this section first, since some systems must be patched while booting. Then type: ::_d_k(0,0)_d_kunix (bring in _d_kunix off root system) The standalone boot program should then read _d_kunix from the root file system you just created, and the system should boot: BBeerrkkeelleeyy UUNNIIXX ((RReevv.. 22..99..55)) MMoonn AAuugg 22 1188::4444::3300 PPDDTT 11998833 mmeemm == xxxxxx CCOONNFFIIGGUURREE SSYYSSTTEEMM:: (Information about various devices will print; most of them will probably not be found until the addresses are set below.) eerraassee==^^??,, kkiillll==^^UU,, iinnttrr==^^CC ## If you are booting from an _x_p with a drive type that is not recognized, it will be necessary to patch the system before it first accesses the root file system. Halt the processor after it has begun printing the version string but before it has finished printing the ``mem = xxx'' string. Place the drive type number corresponding to your drive at location 061472; the addresses for drives 1, 2 and 3 are 061506, 061522 and 061536 respectively. If you plan to use any drives other than 0 before you recompile the system, you should patch these locations. Make the patches and continue the CPU. The value before patching must be zero. If it is not, you have halted too late and should try again. 17 March 1998 Installing/Operating 2.9BSD -14- Bootstrapping UNIX begins by printing out a banner identifying the version of the system that is in use and the date it was compiled. Note that this version is different from the sys- tem release number, and applies only to the operating system kernel. Next the _m_e_m message gives the amount of memory (in bytes) available to user programs. On an 11/23 with no clock control register, a message ``No clock???'' will print next; this is a reminder to turn on the clock switch if it is not already on, since UNIX cannot enable the clock itself. The information about different devices being attached or not being found is produced by the _a_u_t_o_c_o_n_f_i_g(8) program. Most of this is not important for the moment, but later the device table can be edited to correspond to your hardware. However, the tape drive of the correct type should have been detected and attached. The ``erase=...'' message is part of /.profile that was executed by the root shell when it started. The file /.pro- file contained commands to set the UNIX erase, line kill and interrupt characters to be what is standard on DEC systems so that it is consistent with the DEC console interface characters. This is not normal for UNIX, but is convenient when working on a hardcopy console; change it if you like. UNIX is now running, and the Berkeley PDP-11 UNIX Pro- grammer's manual applies. The `#' is the prompt from the Shell, and lets you know that you are the super-user, whose login name is ``root.'' There are a number of copies of _u_n_i_x on the root file system, one for each possible type of root file system device. All but one of them (_x_p_u_n_i_x) has had its symbol table removed (i.e. they have been ``stripped''; see _s_t_r_i_p(1)). The unstripped copy is linked (see _l_n(1)) to _/_u_n_i_x to provide a system namelist for programs like _p_s(1) and _a_u_t_o_c_o_n_f_i_g(8). All of the systems were created from _/_u_n_i_x by the C shell script _/_g_e_n_a_l_l_s_y_s_._s_h. If you had to patch the _x_p type as you booted, you may want to use _a_d_b (see _a_d_b(1)) to make the same patch in a copy of _x_p_u_n_i_x. If you are short of space, you can patch a copy of _/_u_n_i_x instead (setting the rootdev, etc.) and install it as _/_u_n_i_x after verifying that it works. See _/_g_e_n_a_l_l_s_y_s_._s_h for exam- ples of using _a_d_b to patch the system. The system load images for other disk types can be removed. DDoo nnoott rreemmoovvee oorr rreeppllaaccee tthhee ccooppyy ooff _/_u_n_i_x,, hhoowweevveerr,, uunnlleessss yyoouu hhaavvee mmaaddee aa wwoorrkkiinngg ccooppyy ooff iitt tthhaatt iiss ppaattcchheedd ffoorr yyoouurr ffiillee ssyysstteemm ccoonnffiigguurraattiioonn aanndd ssttiillll hhaass aa ssyymmbbooll ttaabbllee.. Many programs use the symbol table of /_u_n_i_x in order to determine the locations of things in memory, therefore /_u_n_i_x should always be an unstripped file corresponding to the current system. If at all possible, you should save the original UNIX bina- ries for your disk configuration (_d_kunix and unix) for use 17 March 1998 Installing/Operating 2.9BSD -15- Bootstrapping in an emergency. There are a few minor details that should be attended to now. The system date is initially set from the root file system, and should be reset. The root password should also be set: ## date _y_y_m_m_d_d_h_h_m_m (set date, see _d_a_t_e(1)) ## passwd root (set password for super-user) NNeeww ppaasssswwoorrdd:: (password will not echo) RReettyyppee nneeww ppaasssswwoorrdd:: 22..55.. IInnssttaalllliinngg tthhee ddiisskk bboooottssttrraapp The disk with the new root file system on it will not be bootable directly until the block 0 bootstrap program for the disk has been installed. There are copies of the boot- straps in /mdec. This is not the usual location for the bootstraps (that is /usr/src/sys/mdec), but it is convenient to be able to install the boot block now. Use _d_d(1) to copy the right boot block onto the disk; the first form of the command is for small disks (rrkk, rrll) and the second form for disks with multiple partitions (hhkk, rrpp, xxpp), substituting as usual for _d_k: ## dd if=_d_kuboot of=/dev/r_d_k0 count=1 or ## dd if=_d_kuboot of=/dev/r_d_k0a count=1 will install the bootstrap in block 0. Once this is done, booting from this disk will load and execute the block 0 bootstrap, which will in turn load /boot (actually, the boot program on the first file system, which is root). The con- sole will print >>bboooott (printed by the block 0 boot) _n_nBBoooott (printed by /boot) :: The '>' is the prompt from the first bootstrap. It automat- ically boots /_b_o_o_t for you; if /_b_o_o_t is not found, it will prompt again and allow another name to be tried. It is a very small and simple program, however, and can only boot the second-stage boot from the first file system. Once /boot is running and prints its ``: '' prompt, boot unix as above, using _d_kunix or unix as appropriate. 17 March 1998 Installing/Operating 2.9BSD -16- Bootstrapping 22..66.. CChheecckkiinngg tthhee rroooott ffiillee ssyysstteemm Before continuing, check the integrity of the root file system by giving the command ## fsck /dev/r_d_k0a (omit the aa for an RK05 or RL). The output from _f_s_c_k should look something like: //ddeevv//rr_x_x00aa FFiillee SSyysstteemm:: // **** CChheecckkiinngg //ddeevv//rr_x_x00aa **** PPhhaassee 11 -- CChheecckk BBlloocckkss aanndd SSiizzeess **** PPhhaassee 22 -- CChheecckk PPaatthhnnaammeess **** PPhhaassee 33 -- CChheecckk CCoonnnneeccttiivviittyy **** PPhhaassee 44 -- CChheecckk RReeffeerreennccee CCoouunnttss **** PPhhaassee 55 -- CChheecckk FFrreeee LLiisstt 223366 ffiilleess 11888811 bblloocckkss xxxxxxxxxx ffrreeee If there are inconsistencies in the file system, you may be prompted to apply corrective action; see the document describing _f_s_c_k for information. The number of free blocks will vary depending on the disk you are using for your root file system. 17 March 1998 Installing/Operating 2.9BDSeDvi-c1e7-and file system configuration 33.. DDEEVVIICCEE AANNDD FFIILLEE SSYYSSTTEEMM CCOONNFFIIGGUURRAATTIIOONN This section will describe ways in which the file sys- tems can be set up for the disks available. It will then describe the files and directories that will be set up for the local configuration. These are the _/_d_e_v directory, with special files for each peripheral device, and the tables in _/_e_t_c that contain configuration-dependent data. Some of these files should be edited after reading this section, and others can wait until later if you choose. The disk config- uration should be chosen before the rest of the distribution tape is read onto disk to minimize the work of reconfigura- tion. 33..11.. DDiisskk ccoonnffiigguurraattiioonn This section describes how to lay out file systems to make use of the available space and to balance disk load for better system performance. The steps described in this sec- tion (3.1) are optional. 33..11..11.. DDiisskk nnaammiinngg aanndd ddiivviissiioonnss Each large physical disk drive can be divided into up to 8 partitions; UNIX typically uses only 3 to 5 partitions. For instance, on an RM03 the first partition, rm0a, is used for a root file system, a backup thereof, or a small file system like /tmp; the second partition, rm0b, is used for swapping or a small file system; and the third partition, rm0c, holds a user file system. Many disks can be divided in different ways; for example, the third section (cc) of the RM03 could instead be divided into two file systems, using the rm0d and rm0e partitions instead, perhaps holding /usr and the user's files. The disk partition tables are speci- fied in the _i_o_c_o_n_f_._c file for each system, and may be changed if necessary. The last partition (hh) always describes the entire disk, and can be used for disk-to-disk copies. WWaarrnniinngg:: for disks on which DEC standard 144 bad sec- tor forwarding is supported, the last track and up to 126 preceeding sectors contain replacement sectors and bad sec- tor lists. Disk-to-disk copies should be careful to avoid overwriting this information. See _b_a_d_1_4_4(8). Bad sector forwarding is optional in the hhkk, hhpp, rrmm, and xxpp drivers. It has been only lightly tested in the latter three cases. 33..11..22.. SSppaaccee aavvaaiillaabbllee The space available on a disk varies per device. The amount of space available on the common disk partitions for /usr is listed in the following table. Not shown in the 17 March 1998 Installing/Operating 2.9BDSeDvi-c1e8-and file system configuration table are the partitions of each drive devoted to the root file system and the swapping area. Type Name Size ----------------------------------- RK06 hk?d 9.2 Mb RK07 hk?c 22.4 Mb RM02, RM03 rm?c 60.2 Mb RM02, RM03 rm?d 30.9 Mb RP03 rp?c 33.3 Mb RP04, RP05, RP06 hp?c 74.9 Mb RP06 hp?d 158.9 Mb RM05 xp?c 115.4 Mb RM05 xp?e 80.9 Mb Each disk also has a swapping area and a root file sys- tem. The distributed system binaries and sources occupy about 38 megabytes. The sizes and offsets of all of the disk partitions are in the manual pages for the disks; see section 4 of the Berkeley PDP-11 UNIX Programmer's manual. Be aware that the disks have their sizes measured in ``sectors'' of 512 bytes each, while the UNIX file system blocks are 1024 bytes each. Thus if a disk partition has 10000 sectors (disk blocks), it will have only 5000 UNIX file system blocks, and you mmuusstt divide by 2 to use 5000 when specifying the size to the _m_k_f_s command. The sizes and offsets in the kernel (ioconf.c) and the manual pages are in 512-byte blocks. If bad sector for- warding is supported for your disk, be sure to leave suffi- cient room to contain the bad sector information when making new file systems. 33..11..33.. LLaayyoouutt ccoonnssiiddeerraattiioonnss There are several considerations in deciding how to adjust the arrangement of things on your disks: the most important is making sure there is adequate space for what is required; secondarily, throughput should be maximized. Swapping space is an important parameter. Since running out of swap space often causes the system to panic, it must be large enough that this does not happen. Many common system programs (the C compiler, the edi- tor, the assembler etc.) create intermediate files in the /tmp directory, so the file system where this is stored also should be made large enough to accommodate most high-water marks; if you have several disks, it makes sense to mount this in a ``root'' or ``swap'' (i.e. first or second parti- tion) file system on another disk. On RK06 and RK07 sys- tems, where there is little space in the hk?c or hk?d file 17 March 1998 Installing/Operating 2.9BDSeDvi-c1e9-and file system configuration systems to store the system source, it is normal to mount /tmp on /dev/hk1a. The efficiency with which UNIX is able to use the CPU is often strongly affected by the configuration of disks. For general time-sharing applications, the best strategy is to try to split the most actively-used sections among sev- eral disk arms. There are at least five components of the disk load that you can divide between the available disks: 1. The root file system. 2. The swap area. 3. The /tmp file system. 4. The /usr file system. 5. The user files. Here are several possibilities for utilizing 2, 3 and 4 disks: +---------+---------------+ | | disks | | +---+-----+-----+ |what | 2 | 3 | 4 | +---------+---+-----+-----+ |root | 1 | 1 | 1 | |tmp | 1 | 3 | 4 | |usr | 1 | 2 | 2 | |swapping | 2 | 3 | 4 | |users | 2 | 1+3 | 1+3 | |archive | x | x | 4 | +---------+---+-----+-----+ The most important consideration is to even out the disk load as much as possible, and to do this by decoupling file systems (on separate arms) between which heavy copying occurs. Note that a long term average balanced load is not important; it is much more important to have instantaneously balanced load when the system is busy. When placing several busy file systems on the same disk, it is helpful to group them together to minimize arm movement, with less active file systems off to the side. Intelligent experimentation with a few file system arrangements can pay off in much improved performance. It is particularly easy to move the root, the /tmp file system and the swapping areas. Note, though, that the disks con- taining the root and swapping area can never be removed while UNIX is running. Place the user files and the /usr directory as space needs dictate and experiment with the other, more easily moved file systems. As an example, consider a system with RM03s. On the first RM03, rrmm00, we will put the root file system in rrmm00aa, and the //uussrr file system in rrmm00cc, which has enough space to 17 March 1998 Installing/Operating 2.9BDSeDvi-c2e0-and file system configuration hold it and then some. If we had only one RM03, we would put user files in the rrmm00cc partition with the system source and binaries, or split them between rrmm00dd and rrmm00ee. The /tmp directory will be part of the root file system, as no file system will be mounted on /tmp. If we had a second RM03, we would create a file system in rrmm11cc and put user files there, calling the file system /mnt. We would keep a backup copy of the root file system in the rrmm11aa disk partition, a file system for /tmp on rrmm00bb, and swap on rrmm11bb. 33..11..44.. IImmpplleemmeennttiinngg aa llaayyoouutt Once a disk layout has been chosen, the appropriate special files for the disk partitions must be created (see Setting up the /dev directory, below). Empty file systems will then be created in the appropriate partitions with _m_k_f_s(8), and the files belonging in the file system can then be restored from tape. The section on setting up the /usr file system contains detailed information on this process. The swap device is specified when the kernel is configured, which is also discussed later. At that time, you may also want to consider whether to use the root device or another file system (e.g. /tmp) for the pipe device (the pipe device is a file system where the kernel keeps temporary files related to pipe I/O; it should be _m_o_u_n_ted before any I/O through pipes is attempted). 33..22.. SSeettttiinngg uupp tthhee //ddeevv ddiirreeccttoorryy Devices are accessed through special files in the file system, made by the _m_k_n_o_d(8) program and normally kept in the /dev directory. Devices to be supported by UNIX are implemented in the kernel by drivers; the proper driver is selected by the major device number and type specified to _m_k_n_o_d. All devices supported by the distribution system already have nodes in /dev. They were created by the /dev/MAKE shell script. It is easiest to rebuild this directory from the beginning with the correct devices for your configuration. First, determine the UNIX names of the devices on your system (e.g. _d_h, _l_p, _x_p). Some will be the same as the names of devices on the generic system. Others need not be. See section 4 of the UNIX Programmer's Manual. Next create a new directory /newdev, copy /dev/MAKE into it, edit MAKE to provide an entry for local needs, replacing the case LOCAL, and run it to generate the desired devices in the /newdev directory. The LOCAL entry can be used for any unusual devices, and to rename standard devices as desired. It should also move the node for the disk partition being used as the swap area to _s_w_a_p (or, if swap is after a file system as on RK05 or RL disks, link the other node to _s_w_a_p). Different devices are specified to MAKE in various ways. Terminal multiplexors (DZ and DH) are specified by boards, 17 March 1998 Installing/Operating 2.9BDSeDvi-c2e1-and file system configuration and 8 or 16 nodes will be made, as appropriate. Disks are made by partition, for example xp0c, so that you may make the nodes corresponding to the file systems that you intend to use. Note that _h_p, _r_m and _x_p are actually synonyms, but you should use the name corresponding to the driver you plan to use. The kernel configuration section (section 5.4.1) has more information. For tape drives, there are different invocations for different types of controllers, although the nodes produced will have the same names. The different types are _h_t, _t_m and _t_s, as above, and also _u_t, which is used for the Emulex TC-11 and other TM-11 emulations that are also capable of selecting 1600 or 800 bpi under software control. Making _h_t_0 or _u_t_0 will result in nodes _m_t_0 and _m_t_1 (800 and 1600 bpi, respectively) and parallel nodes for other options; _h_t_1 uses the names _m_t_2 and _m_t_3. See _h_t(4) and _t_m(4). In contrast, the MAKE script makes only one set of nodes for _t_m or _t_s, without changing the unit number specified. Different sites use different naming conventions for tapes; you could use the LOCAL entry in MAKE to move the tape files to your favorite names. As an example, if your machine had a single DZ-11, two DH-11s, an RP03 disk, two RP06 disks, and a TM03 tape for- matter you would do: ## cd / ## mkdir newdev ## cp /dev/MAKE /newdev/MAKE ## cd newdev ## ./MAKE dz0 dh1 ht0 std LOCAL ## ./MAKE rp0a rp0b rp0c hp0a hp0b hp0c hp1a hp1b hp1d hp1e Note the ``std'' argument here that causes standard devices such as _c_o_n_s_o_l_e, the console terminal, to be created. You can then do ## cd / ## mv dev genericdev ; mv newdev dev ## sync to install the new device directory. Once you are confident that the new directory is set up properly, you can remove /genericdev. 33..33.. EEddiittiinngg ssyysstteemm--ddeeppeennddeenntt ccoonnffiigguurraattiioonn ffiilleess There are a number of small files in /_e_t_c that are used by various programs to determine things about the local con- figuration. At this point, several of these should be edited to describe the local configuration. You may have old versions of some of them which you may want to use, or you may edit the files that are provided as examples. Some of this may be done later at your convenience, but is 17 March 1998 Installing/Operating 2.9BDSeDvi-c2e2-and file system configuration presented here for organization. Both //eettcc//ddttaabb and //eettcc//ffssttaabb should be edited now. 33..33..11.. //eettcc//ddttaabb This file contains the list of devices which will be checked at boot time by _a_u_t_o_c_o_n_f_i_g(8). The devices that are listed are tested to see whether they exist and have the correct register addresses and interrupt vectors. If they do, and the kernel has a corresponding driver routine, _a_u_t_o_- _c_o_n_f_i_g notifies the driver that the device exists at that address. In this way, the addresses and vectors of most devices do not need to be compiled into the operating sys- tem. The exception is that disks must be preconfigured if they are to be used as root file systems. This file should be edited to include all of the devices on the system with the exception of the clock and console device. Other device entries can be deleted or com- mented out with a '#' at the beginning of the line. The format of the entries is defined in _d_t_a_b(5). _A_u_t_o_c_o_n_f_i_g(8) describes the autoconfiguration process. One word of cau- tion: if a device fails to interrupt as expected, and if its unit number is specified (not a '?' wildcard), _a_u_t_o_c_o_n_- _f_i_g will notify the driver that the device is nnoott present, and preconfigured devices (like root disks) could be discon- nected. Thus, it is probably best to use a '?' instead of a unit number for your root disks until you are confident that the probe always finds that disk, especially if your disk controller is an emulation of another disk type. Disks that are not used as boot devices for UNIX can be properly listed with unit numbers. 33..33..22.. //eettcc//ffssttaabb This file contains the list of file systems normally mounted on the system. Its format is defined in _f_s_t_a_b(5). Programs like _d_f(1) and _f_s_c_k(8) use this list to control their actions. Each disk partition that has been assigned a function should be listed here. See the manual pages for specifics on how to configure this file. 33..33..33.. //eettcc//iiddeenntt The banner printed by _g_e_t_t_y(8) is read from /etc/ident. Edit this file to the banner you wish to use. It may con- tain special characters to clear terminal screens, etc., but note that the same file is used for all terminals. 33..33..44.. //eettcc//mmoottdd The contents of /etc/motd, the ``message of the day,'' is displayed at the terminal when a user is logged in by _l_o_g_i_n(1). 17 March 1998 Installing/Operating 2.9BDSeDvi-c2e3-and file system configuration 33..33..55.. //eettcc//ppaasssswwdd,, //eettcc//ggrroouupp These files obviously need local modifications. See the section on adding new users. Entries for pseudo-users (user IDs that are not used for logins) have password fields containing ``***'', since encrypted passwords never not con- tain asterisks. 33..33..66.. //eettcc//rrcc As the system begins multiuser operations, it executes the commands in /etc/rc (see _i_n_i_t(8)). Most of the commands in this file are standard and should not be changed, includ- ing the section for checking file systems after a reboot. These commands will be ignored if autoreboot is not enabled. You should edit /etc/rc to set your machine's name. Look for the line /etc/hostname hostnameunknown and change _h_o_s_t_n_a_m_e_u_n_k_n_o_w_n to the name of your machine. This name will be used by _M_a_i_l(1) and _u_u_c_p(1) (among others) and should correspond to the name by which your machine is known to external networks (if any). At this time you may wish to add additional commands to this file if you need to start additional daemons, remove old lock files, or perform any other cleanup as the system comes up. 33..33..77.. CCoonnffiigguurriinngg tteerrmmiinnaallss If UNIX is to support simultaneous access from more than just the console terminal, the file /etc/ttys (_t_t_y_s(5)) has to be edited. Terminals connected via DZ interfaces are convention- ally named ttttyy_d_d where _d_d is a decimal number, the ``minor device'' number. The lines on dz0 are named /dev/tty00, /dev/tty01, ... /dev/tty07. Lines on DH interfaces are con- ventionally named ttttyyhh_x, where _x is a hexadecimal digit. If more than one DH interface is present in a configuration, successive terminals would be named ttttyyii_x, ttttyyjj_x, etc. To add a new terminal be sure the device is configured into the system, that the special file for the device has been made by /dev/MAKE, and the special file exists. Then set the first character of the appropriate line of /etc/ttys to 1 (or add a new line). The first character may also be 3 if the line is also to be used in maintenance mode (see _i_n_i_t(8)). The second character of each line in the /etc/ttys file lists the speed and initial parameter settings for the ter- minal. The most common choices, from _g_e_t_t_y(8), are: 17 March 1998 Installing/Operating 2.9BDSeDvi-c2e4-and file system configuration 0 300-1200-150-110 3 1200-300 4 300 (e.g. console) 5 300-1200 6 1200 7 2400 8 4800 9 9600 B autobaud Here the first speed is the speed a terminal starts at, and ``break'' switches speeds. Thus a newly added terminal /dev/tty00 could be added as 19tty00 if it was wired to run at 9600 baud. The ``B'' indicates that _g_e_t_t_y should attempt to guess a line's speed when the user types a carriage return or control-C. Note that this requires kernel support. See section 5.3.6 below. Dialup terminals should be wired so that the carrier is asserted only when the phone line is dialed up. For non- dialup terminals from which modem control is not available, you must either wire back the signals so that the carrier always appears to be present, or (for lines on a DH-11 or DZ-11) add 0200 to the minor device number to indicate that carrier is to be ignored. See _d_h(4) and _d_z(4) for details. You should also edit the file /etc/ttytype placing the type of each terminal there (see _t_t_y_t_y_p_e(5)). When the system starts running multi-user, all termi- nals that are listed in /etc/ttys having a 1 or 3 as the first character of their line are enabled. If, during nor- mal operations, it is desired to disable a terminal line, the super-user can edit the file /etc/ttys, change the first character of the corresponding line to 0 and then send a hangup signal to the _i_n_i_t process, by typing (see _k_i_l_l(1)) ## kill -1 1 or ## kill -HUP 1 Terminals can similarly be enabled by changing the first character of a line from a 0 to a 1 and sending a hangup to _i_n_i_t. Note that if a special file is inaccessible when _i_n_i_t tries to create a process for it, init will print a message on the console and try to reopen the terminal every minute, reprinting the warning message every 10 minutes. 17 March 1998 Installing/Operating 2.9BDSeDvi-c2e5-and file system configuration Finally note that you should change the names of any dialup terminals to ttyd? where ? is in [0-9a-f] since some programs use this property of the names to decide whether a terminal is a dialup. Shell commands to do this should be put in the /dev/MAKE script under case LOCAL. 17 March 1998 Installing/Operating 2.9BSD -26- /usr setup 44.. SSEETTTTIINNGG UUPP TTHHEE //uussrr FFIILLEE SSYYSSTTEEMM The next step in bringing up the 2.9BSD distribution is to read in the binaries and sources on the /usr file system. This will also demonstrate how to add new file systems in general, and the overall procedure can be repeated to set up additional file systems. There are two portions of the /usr file system, one on each tape. The first tape contains the binary directories, manual pages and documentation, as well as skeletal directories such as spool and msgs. If you have room, it is easiest to extract everything. The size of the entire /usr file system image on the distribution tapes is 38 megabytes. It will not fit on a single RK05, RK06/7 or RL01/2. In these cases, the /usr file system will have to be extracted in sections or split across multiple disks. The _b_i_n, _i_n_c_l_u_d_e, _l_i_b, and _u_c_b subdirectories are essential. The system sources will also be needed to reconfigure the kernel; they are in /usr/src/sys. The _a_d_m, _d_i_c_t, _m_s_g_s, _p_r_e_- _s_e_r_v_e, _s_p_o_o_l, _s_y_s and _t_m_p directories may also be extracted to provide a skeletal system. The first part of this sec- tion describes how to extract /usr as part of a full boot- strap; the second part explains how to install 2.9BSD as an upgrade to a 2.8BSD system if you decide not to perform a full bootstrap. 44..11.. FFuullll bboooottssttrraapp pprroocceedduurree This procedure will create a new file system and extract the /usr directory into it. First determine the name of the disk on which you plan to place the new file system, for example rm0c, and substitute it for _d_i_s_k throughout this section. You may want to create a small ``prototype'' file to describe the file system (see _m_k_f_s(8)) in order to change the size of the inode list. This is the same as the maximum number of files that can be created on the file system. The default is to allow 16 inodes (occupy- ing one block) per 24 file system blocks, allowing the file system to be completely filled with small files (1-2 blocks). This is more than required for /usr and other file systems which have larger average file size. If you decide to set up a prototype file for _m_k_f_s, use its name for _p_r_o_t_o below. The prototype file needs to contain only the name of the bootstrap, the sizes, and the line for the root direc- tory (don't forget the '$' to terminate). Look up the cor- rect size for this file system in the manual section for the disk. Note that the size given to _m_k_f_s is in file system blocks of 1024 bytes, and thus the sizes in the manual page will have to be divided by 2. If not using a prototype file, substitute the size for _p_r_o_t_o in the mkfs command below. Finally, recall the interleaving parameters _m and _n that you used in making the root file system. They are in the table in section 2.2. Comments are enclosed in ( ); 17 March 1998 Installing/Operating 2.9BSD -27- /usr setup don't type these. Then execute the following commands (sub- stituting _r_m_t_1 and _n_r_m_t_1 for _r_m_t_0 and _n_r_m_t_0 respectively if you have a 1600 bpi tape on an ht or tm controller): ## /etc/mkfs /dev/r_d_i_s_k _p_r_o_t_o _m _n (create empty user file system) iissiizzee == _n_n_n_n_n (the count of available inodes) mm//nn == _m _n (free list interleave parameters) (this takes a few minutes) ## /etc/mount /dev/_d_i_s_k /usr (mount the usr file system) ## cd /usr (make /usr the current directory) (make sure that the first tape is mounted) ## mt -t /dev/nrmt0 fsf 7 (skip first seven tape files) ## tar xpf /dev/rmt0 (extract the /usr file system binaries) (this takes about 20 minutes) (now mount the second tape) ## tar xpf /dev/rmt0 (extract the /usr file system sources) (this takes another 20 minutes) You can now check the consistency of the /usr file sys- tem by doing ## cd / (back to root) ## /etc/umount /dev/_d_i_s_k (unmount /usr) ## fsck /dev/r_d_i_s_k To use the /usr file system, you should now remount it by saying ## /etc/mount /dev/_d_i_s_k /usr If you are installing the distribution on a PDP11/44, 11/45, or 11/70 (machines with separate instruction and data space) you should test and install the separate I/D versions of csh, ex, etc. in /usr/70. Note, however, that these binaries assume the existence of hardware floating point support. 44..22.. BBoooottssttrraapp ppaatthh 22:: uuppggrraaddiinngg 22..88BBSSDD Begin by reading the other parts of this document to see what has changed since the last time you bootstrapped the system. Also look at the new manual sections provided to you. If you have local system modifications to the ker- nel to install, look at the document ``Changes in the Kernel in 2.9BSD'' to get an idea of how the system changes will affect your local mods. Disclaimer: there are a very large number of changes from 2.8BSD to 2.9. This section may not be complete, and if a new program fails to work after being recompiled, you may find that additional libraries or other 17 March 1998 Installing/Operating 2.9BSD -28- /usr setup components may also need to be updated. There are 6 major areas of changes that you will need to incorporate to convert to the new system: 1. The new kernel and the associated programs that imple- ment job control or read kernel memory: autoconfig, csh, the jobs library, login, ps, pstat, w, etc. 2. The programs related to system reboots and shutdowns. 3. The programs directly related to user text overlays: adb and ld. 4 The C compiler driver, C preprocessor, and assembler. 5 The new version of the standard I/O library. 6. Other programs with significant bug fixes, significant improvements, or which were previously unavailable because they had not been overlaid. Here is a step-by-step guide to converting. Before you begin you should do a full backup of your root and /usr file systems as a precaution against irreversible mistakes. 1. Set the shell variable ``nbsd'' to the name of a direc- tory where an empty file system can be mounted and a quantity of material from the tape (you should allow for about 38 megabytes) can be extracted. Choose a disk of sufficient size to hold this quantity of mate- rial, make a file system, and mount $nbsd on this disk. Next, restore (see _r_e_s_t_o_r(8)) the root file system dump image to this disk. Finally, change directory to ``$nbsd/usr'', and extract the eighth file from the first distribution tape and all of the second tape using _t_a_r (see _t_a_r(1)). 2. Install the new include files by copying $nbsd/usr/include/*.h to /usr/include and $nbsd/usr/include/sys/*.h to /usr/include/sys. Install the C compiler driver from the new system by copying $nbsd/bin/cc to /bin/cc. Install the assembler from the new system by copying $nbsd/bin/as to /bin/as and $nbsd/lib/as2 to /lib/as2. Install the new C prepro- cessor by copying $nbsd/lib/cpp to /lib/cpp. Install the new versions of adb and ld by copying $nbsd/bin/adb and $nbsd/bin/ld to /bin. 3. Reconfigure the system in $nbsd/usr/src/sys to corre- spond to your configuration according to the instruc- tions in section 5. 17 March 1998 Installing/Operating 2.9BSD -29- /usr setup 4. Put in the new versions of the following programs: /bin: csh, kill, login, iostat, ps, pstat, vmstat /etc: autoconfig, fsck, init, mount, reboot, savecore, shutdown, umount /usr/ucb: ex, w Merge any local changes to /etc/rc into $nbsd/etc/rc. Put the resulting file in /etc/rc. Create the direc- tory /usr/sys and perhaps some files in this directory (read _s_a_v_e_c_o_r_e(8)). Make a device description file for _a_u_t_o_c_o_n_f_i_g. See _d_t_a_b(5) and _a_u_t_o_c_o_n_f_i_g(8). 5. Try bootstrapping the new system; it should now work. Make sure to write new instructions to your operators. 6. Incorporate some other important bug fixes or enhance- ments: a) Replace the file tmac.an in the directory /usr/lib/tmac with the version from $nbsd/usr/lib/tmac. Replace the file /usr/lib/me/local.me with the version from $nbsd/usr/lib/me; copy $nbsd/usr/lib/me/refs.me to /usr/lib/me. b) Install the new C library source, /usr/src/lib/c, rebuild and reinstall /lib/libc.a and /usr/lib/libovc.a. c) Install the jobs library, /usr/src/lib/jobs and build and install /usr/lib/libjobs.a and /usr/lib/libovjobs.a. d) Replace the directory /usr/src/cmd/refer. Then rebuild and reinstall the programs. e) Install the new Mail source, /usr/src/ucb/Mail and reinstall /usr/ucb/Mail. f) If the target machine is a nonseparate I/D CPU, install the new _l_e_x and _y_a_c_c directories, compile and install the programs. g) Install the new version of _t_a_r from $nbsd/usr/src/cmd/tar.c and also the program _m_t from $nbsd/usr/src/ucb/mt.c. h) Merge your changes to /usr/src/ucb/termcap/reorder and reinstall the terminal data base, /etc/termcap. Install the new terminal library, /usr/src/ucb/termlib, remake and reinstall 17 March 1998 Installing/Operating 2.9BSD -30- /usr setup /usr/lib/libtermcap.a and /usr/lib/libovtermcap.a. Then make and install the new version of _e_x_. i) If you want the new version of the Pascal system incorporating overlays (for nonseparate I/D CPUs), remake the directories _p_i and _p_x in $nbsd/usr/src/cmd and install the programs. j) Install the new F77 compiler, /usr/src/cmd/f77, and the new libraries, /usr/src/lib/lib*77. Then remake and reinstall them. k) Install the new library sources, /usr/src/lib/{ape,curses,m,mp,plot} and remake and reinstall the new libraries. l) Install new versions of as many of the following programs as you choose: 512dumpdir, 512restor, atrun, cat, catman, ccat, compact, checkobj, ctags, df, diff, du, egrep, error, expand, fgrep, find, from, grep, hostname, jove, l11, lint, ln, lock, login, lpr, ls, m11, make, man, mkfs, more, msgs, mv, ncheck, printenv, pq, ranm, rewind, rm, rmdir, sed, setquota, size, sort, split, sq, strings, strip, stty, sysline, tail, tbl, tset, ul, uncompact, unexpand, vsh, wc. m) Install the modified or new administrative pro- grams: ac, getty, last. n) Install some security fixes in the mail systems by installing new sources for berknet (/usr/src/ucb/berknet), delivermail (/usr/src/ucb/delivermail), mail (/usr/src/cmd/mail.c), and secret mail (/usr/src/cmd/xsend), and remaking and rein- stalling the new binaries. o) Install the new version of uucp (/usr/src/cmd/uucp). p) Install the news (/usr/contrib/news) or notes (/usr/contrib/notes) bulletin board system if you wish. q) Install the new _e_q_n(1) symbol macros, /usr/public/eqnSyms. r) Install manual pages corresponding to the new and changed programs. s) Remove the old programs /bin/ovas, /bin/ovld, /lib/ovas2, and /bin/ovadb. Remove the libucbpath library. Remove the old version of reset and link 17 March 1998 Installing/Operating 2.9BSD -31- /usr setup the new version of tset to reset. 17 March 1998 Installing/Operating 2.9BSD -32- Kernel configuration 55.. CCOONNFFIIGGUURRIINNGG AANNDD CCOOMMPPIILLIINNGG TTHHEE KKEERRNNEELL This section describes procedures used to set up a PDP-11 UNIX kernel (operating system). It explains the lay- out of the kernel code, compile time options, how files for devices are made and drivers for the devices are configured into the system and how the kernel is rebuilt to include the needed drivers. Procedures described here are used when a system is first installed or when the system configuration changes. Procedures for normal system operation are described in the next section. We also suggest ways to organize local changes to the kernel. 55..11.. KKeerrnneell oorrggaanniizzaattiioonn The kernel source is kept in the subdirectories of /usr/src/sys. The directory /usr/src/sys/sys contains the mainline kernel code, implementing system calls, the file system, memory management, etc. The directory /usr/src/sys/dev contains device drivers and other low-level routines. The header files and scripts used to compile the kernel are kept in /usr/src/sys/conf, and are copied from there into a separate directory for each machine configura- tion. It is in this directory, /usr/src/sys/_m_a_c_h_i_n_e, that the kernel is compiled. 55..22.. CCoonnffiigguurriinngg aa SSyysstteemm The kernel configuration of each PDP-11 UNIX system is described by a set of header files (one for each device driver) and one file of magic numbers (ioconf.c) stored in a subdirectory of /usr/src/sys for each configuration. Pick a name for your machine (call it PICKLE). Then in the /usr/src/sys/conf directory, create a configuration file PICKLE describing the system you wish to build, using the format in _c_o_n_f_i_g(8). This is most easily done by making a copy of the GENERIC file used for the distributed UNIX binary. Many of the fields in the configuration file corre- spond to parameters listed in the remainder of this section, which should be scanned before proceeding. See especially section 5.4.3 on how to set up automatic reboots and dumps. Then use _c_o_n_f_i_g to create a system directory ../PICKLE with ``config PICKLE.'' Note the difference between _c_o_n_f_i_g and _a_u_t_o_c_o_n_f_i_g. _C_o_n_f_i_g sets up a directory in which the kernel will be compiled, with all of the system-specific files used in compilation, and specifies what devices will potentially be supported. _A_u_t_o_c_o_n_f_i_g adapts the running kernel to the hardware actually present, by testing and setting the regis- ter addresses and interrupt vectors. _C_o_n_f_i_g does most of the work of configuration, but local needs will dictate some changes in the options and 17 March 1998 Installing/Operating 2.9BSD -33- Kernel configuration parameters in the header files. All of the options are listed in the next section. Examine whoami.h, localopts.h, param.h, and param.c and make any changes required; it might also be wise to look through the header files for the devices that you have configured, to check any options spe- cific to the device drivers that are listed there. After you have finished configuring a kernel and tested it, you should install whoami.h in /usr/include, and copy localopts.h and param.h into /usr/include/sys. This will allow user-level programs to stay in sync with the running kernel. If you wish to change any disk partition tables or device control status register addresses (other than those configured at boot time by _a_u_t_o_c_o_n_f_i_g(8)), edit ioconf.c and change the appropriate line(s). The file l.s contains the interrupt vectors and interface code and may also be edited if necessary, but usually will require no change. Both c.c and l.s include support for all normal devices according to the header files per device, and with autoconfiguration, the actual vectors need not be specified in advance. Finally, examine the Makefile, especially the options near the top and the load rules. If you have placed the include files in the standard directories, you shouldn't have to make any changes to the options there. The following sections give short descriptions of the various compile-time options for the kernel, and more exten- sive information on the autoreboot and disk monitoring setup. After verifying that those features are configured correctly for your system, you can proceed to kernel compi- lation. 55..33.. CCoommppiillee TTiimmee OOppttiioonnss The 2.9BSD kernel is highly tunable. This section gives a brief description of the many compile-time options available, and references to sections of the Berkeley PDP-11 UNIX Programmer's manual where more information can be found. Options fall into four categories; the letters fol- lowing each will be used to mark the options throughout the rest of this section. Standard (S) These include options which we consider necessary for reasonable system performance or resiliency. Desirable (D) These include many other fea- tures that are convenient but which may be turned off if system size is critical. The user programs and libraries distributed with 2.9BSD 17 March 1998 Installing/Operating 2.9BSD -34- Kernel configuration generally assume that these are turned on, so turning them off may necessitate recompiling libraries or pro- grams. These options, along with those designated ``stan- dard'', have received the most thorough testing. Configuration Dependent (C) Options that depend on such things as the physical con- figuration or speed issues fall into this category. Experimental (X) New features that have not been well tested, options that have known problems, or ones that we do not normally use are listed as experimen- tal. You should not use such options unless the problems listed are not considerations for your system, or you are willing to watch things closely and possibly do some debugging. The following sections list the parameters and options used in the kernel. The parameters (section 5.3.2) have numeric values, usually table sizes, and most of them are in param.h or param.c. Those that are in param.h are typically not changed, with the possible exception of MMAAXXMMEEMM, as their values are set by convention. The option flags are either defined or undefined to enable or disable the corresponding feature, with the exception of UUCCBB__NNKKBB, which is unlikely to change. Each option is marked with a letter to indicate into which of the four categories above it falls. 55..33..11.. HHaarrddwwaarree EENNAABBLLEE3344 XX Automatically detect and support Able Computer's ENABLE/34|- memory management board. This option implies UUNNIIBBUUSS__MMAAPP. NNOONNFFPP CC Do not compile in code to automatically detect and support an FP11 floating point processor. Also, include a fast illegal-instruction trap handler and modify the signal routines to make it possible to run programs using the floating-point interpreter under trace. ----------- |-ENABLE/34 is a trademark of Able Computer, Inc. 17 March 1998 Installing/Operating 2.9BSD -35- Kernel configuration NNOONNSSEEPPAARRAATTEE CC Do not attempt to support separate I/D user programs. PPAARRIITTYY CC Recognize and deal with cache and memory parity traps. PPDDPP1111 CC This should be set to the CPU type of the target machine (23, 24, 34, 40, 44, 45, 60, 70, or GENERIC). You should use 34 for an 11/34A and 45 for an 11/55. GENERIC should be used to build a system which runs on a variety of CPUs. It was used to make the distributed kernels. MMEENNLLOO__KKOOVV and NNOONNSSEEPPAARRAATTEE are defined if PPDDPP1111 is 23, 24, 34, 40, or 60. MMEENNLLOO__KKOOVV is also defined if PPDDPP1111 is GENERIC. UUNNIIBBUUSS__MMAAPP is defined if PPDDPP1111 is 44, 70, or GENERIC. SSMMAALLLL CC Use smaller (by about a factor of 8) queues and hash tables. UUNNIIBBUUSS__MMAAPP CC Compile in code to detect (and support if present) a UNIBUS map. 55..33..22.. PPaarraammeetteerrss 55..33..22..11.. GGlloobbaall ccoonnffiigguurraattiioonn MMAAXXUUSSEERRSS This is the maximum number of users the system should normally expect to sup- port. _C_o_n_f_i_g sets this from the corre- sponding field in the description file; the definition is copied into the system Makefile rather than a header file. It is not intended to be a hard limit. It is used in sizing other parameters (CCMMAAPPSSIIZZ, NNFFIILLEE, NNIINNOODDEE, NNPPRROOCC, NNTTEEXXTT, and SSMMAAPPSSIIZZ). The formulae are found in _p_a_r_a_m_._c. Reasonable values for MMAAXXUUSSEERRSS might be 3 or 4 on a small system (11/34, 11/40), 15 for an 11/44 with a reasonable amount of memory, and 15-30 for an 11/70 system. TTIIMMEEZZOONNEE The number of minutes westward from Greenwich. _C_o_n_f_i_g sets this from the corresponding field in the description file. Examples: for Pacific Standard time, 8 (* 60); for EST, 5. DDSSTTFFLLAAGG Should be 1 if daylight savings time applies in your locality and 0 other- wise. _C_o_n_f_i_g sets this from the field 17 March 1998 Installing/Operating 2.9BSD -36- Kernel configuration in the description file. HHZZ This is the line clock frequency (e.g. 50 for a 50 Hz. clock). 55..33..22..22.. TTuunnaabbllee ppaarraammeetteerrss CCMMAAPPSSIIZZ This is the number of fragments into which memory can be broken. If this number is too low, the kernel's memory allocator may be forced to throw away a section of memory being freed because there is no room in the map to hold it. In this case, a diagnostic message is printed on the console. Normally scaled automatically according to MMAAXXUUSSEERRSS. MMAAXXMMEEMM This sets an administrative limit on the amount of memory a process may have. It is specified as (_n_n*16), where the first number is the desired value in kilobytes (the product is in clicks). This number is usually considerably lower than the theoretical maximum (304 Kb for a non- separate I/D CPU, 464 Kb for a separate I/D CPU, assuming MMEENNLLOO__OOVVLLYY is defined). Normal values are 128 Kb if there is no UNIBUS map (maximum physical memory 248 Kb), otherwise 200 Kb. NNBBUUFF This sets the size of the system buffer cache. It can be no greater than 248. If UUCCBB__NNKKBB is defined, these are 1024 byte buffers. Otherwise, they are 512 byte buffers. The buffers are not in kernel data space, but are allocated at boot time. Normally scaled automati- cally according to MMAAXXUUSSEERRSS, but should be examined in the light of the disk load and amount of memory. For a small to medium system, around 20 buffers should be sufficient; a large system with many disks might use 40 to 60 or more. NNCCAALLLL This is the maximum number of simultane- ous callouts (kernel event timers). Callouts are used to time events such as tab or carriage return delays. Normally scaled automatically according to MMAAXXUUSSEERRSS. NNCCLLIISSTT This is the maximum number of clist seg- ments. Clists are small buffer areas, 17 March 1998 Installing/Operating 2.9BSD -37- Kernel configuration used to hold tty characters while they are being processed. If UUCCBB__CCLLIISSTT is defined, they are not in kernel data space, and this number must be less than 512 if you are using 14 character clists (the default), or 256 for 30 character clists. (The clist size, CCBBSSIIZZEE, is in param.h.) NNDDIISSKK This is the maximum number of disks and controllers for which I/O statistics can be gathered. See _i_o_s_t_a_t(8). Care must be taken that this is large enough for the parameters for each disk (_X_X_DKN and number of disks; see the section on disk monitoring). NNFFIILLEE This sets the maximum number of open files. An entry is made in this table each time a file is ``opened'' (see _c_r_e_a_t(2)), _o_p_e_n(2)). Processes share these table entries across forks (see _f_o_r_k(2), _v_f_o_r_k(2)). Normally scaled automatically according to MMAAXXUUSSEERRSS. NNIINNOODDEE This sets the size of the inode table. There is one entry in the inode table for each open file or device, current working or root directory, saved text segment, active quota node (if UUCCBB__QQUUOOTTAASS is defined), and mounted file system. Normally scaled automatically according to MMAAXXUUSSEERRSS. NNMMOOUUNNTT This indicates the maximum number of mountable file systems. It should be large enough that you don't run out at inconvenient times. NNPPRROOCC This sets the maximum number of active processes. Normally scaled automati- cally according to MMAAXXUUSSEERRSS. NNTTEEXXTT This sets the maximum number of active shared text images (including inactive saved text segments). Normally scaled automatically according to MMAAXXUUSSEERRSS. SSMMAAPPSSIIZZ This is the analogy of CCMMAAPPSSIIZZ for sec- ondary memory (swap space). Normally scaled automatically according to MMAAXXUUSSEERRSS. 17 March 1998 Installing/Operating 2.9BSD -38- Kernel configuration 55..33..22..33.. PPaarraammeetteerrss tthhaatt aarree sseett bbyy ccoonnvveennttiioonn CCAANNBBSSIIZZ This sets the maximum size of a terminal line input buffer. If using the old tty line discipline, exceeding this bound causes _a_l_l characters to be lost. In the new tty line discipline, no more charac- ters are accepted until there is room. Normally 256. MMAAXXSSLLPP This is the maximum time a process can sleep before it is no longer considered a ``short term sleeper.'' It is used only if UUCCBB__MMEETTEERR is defined. Normally 20. MMAAXXUUPPRRCC This sets the maximum number of pro- cesses each user is allowed. Normally 20, but can be lower on heavily loaded systems. MMSSGGBBUUFFSS This is the number of characters saved from system error messages. It is actu- ally the size of circular buffer into which messages are temporarily saved. It is expected that _d_m_e_s_g(8) will be run by _c_r_o_n(8) frequently enough that no message is overwritten before it can be saved in the system error log. Normally 128. NNCCAARRGGSS This is the maximum size of an _e_x_e_c(2) argument list (in bytes). Normally 5120. NNOOFFIILLEE This sets the maximum number of open files each process is allowed. Normally 20. SSIINNCCRR The increment (in clicks) by which a process's stack is expanded when a stack overflow segmentation fault occurs. Normally 20. SSSSIIZZEE The initial size (in clicks) of a pro- cess's stack. This should be made larger if commonly run processes have large data areas on their stacks. Nor- mally 20. 55..33..33.. GGeenneerraall OOppttiioonnss 17 March 1998 Installing/Operating 2.9BSD -39- Kernel configuration AACCCCTT DD Enable code which (optionally) writes an accounting record for each process at exit. See _l_a_s_t_c_o_m_m(1), _s_a(1), _a_c_c_t(2), _a_c_c_t_o_n(8). CCGGLL__RRTTPP CC Support a system call which marks a pro- cess as a ``real time'' process, giving it higher priority than all others. See _r_t_p(2). DDIIAAGGNNOOSSTTIICC CC Turn on more stringent error checking. This enables various kernel consistency checks which are considered extremely unlikely to fail. It is useful when the system is inexplicably crashing. IINNSSEECCUURREE CC Do not turn off the set-user-id or set- group-id permissions on a file when it is written. MMEENNLLOO__JJCCLL DD Support reliable signal handling and enhanced process control features. See _s_i_g_s_y_s(2j), _j_o_b_s(3j), _s_i_g_s_e_t(3j). This option requires UUCCBB__NNTTTTYY. MMEENNLLOO__KKOOVV CC Support automatic kernel text overlays. This is required for nonseparate I/D systems and is defined automatically if PPDDPP1111 is defined to be 23, 24, 34, 40, 60, or GENERIC. MMEENNLLOO__OOVVLLYY DD Support automatic user text overlays. This is required in order to run certain programs (e.g. _e_x version 3.7 or, on nonseparate I/D systems, the process control C shell). OOLLDDTTTTYY CC Support the standard V7 tty line disci- pline (see _t_t_y(4)). This must be defined if UUCCBB__NNTTTTYY is not defined. UUCCBB__AAUUTTOOBBOOOOTT DD Allows the kernel to automatically reboot itself, either on demand (see _r_e_b_o_o_t(2) and _r_e_b_o_o_t(8)) or after _p_a_n_i_cs. This option requires a little planning; see section 5.4.3. TThhiiss ooppttiioonn rreeqquuiirreess UUCCBB__FFSSFFIIXX.. UUCCBB__CCLLIISSTT CC Map clists out of kernel virtual data space. If there is sufficient space in kernel data for an adequate number of clists, this option should not used. Mostly used on large systems, or on sys- tems where kernel data space is tight. 17 March 1998 Installing/Operating 2.9BSD -40- Kernel configuration UUCCBB__GGRRPPMMAASSTT CC Allow one user to be designated a ``group super-user,'' able to perform various functions previously restricted to root or the file's owner alone. In the kernel, users whose group and user ids are the same are granted the same permissions with respect to files in the same group as is the owner. User level software implements other permissions, allowing the group super-user to change the password of a user in the same group. The most common use for this is in allowing teaching assistants to over- see students. UUCCBB__NNEETT XX Enable code implementing a PDP-11 port of Berkeley's version of TCP/IP. The code is experimental and the implementa- tion is incomplete. UUCCBB__NNTTTTYY SS Support the Berkeley tty line discipline (see _t_t_y(4) and _n_e_w_t_t_y(4)). This must be defined if OOLLDDTTTTYY is not defined. UUCCBB__PPGGRRPP CC Fix a bug in the way standard V7 counts a user's processes. This should be enabled only if MMEENNLLOO__JJCCLL is undefined, since the notion of process groups is completely different in the two cases. If UUCCBB__PPGGRRPP and MMEENNLLOO__JJCCLL are both defined, the limit on the number of pro- cesses allowed per user (MMAAXXUUPPRRCC) is effectively eliminated. UUCCBB__SSCCRRIIPPTT XX Allow scripts to specify their own interpreters. For example, executing a script beginning with ``#! /bin/sh'' causes /bin/sh to be executed to inter- pret the script. This is not (yet) the same as the facility on 4.1BSD VMUNIX, and probably needs a little work. The Bourne shell, /bin/sh, would need modi- fication also. UUCCBB__UUPPRRIINNTTFF DD Write error messages directly on a user's terminal when the user causes a file system to run out of inodes or free blocks, or on certain mag tape errors. UUCCBB__VVHHAANNGGUUPP DD Support a system call which allows _i_n_i_t(8) to revoke access to a user's terminal when the user has logged out. This is used to give new users ``clean'' terminals on login. 17 March 1998 Installing/Operating 2.9BSD -41- Kernel configuration VVIIRRUUSS__VVFFOORRKK DD Implement a much more efficient version of fork in which parent and child share resources until the child _e_x_e_cs. See _v_f_o_r_k(2). Note that this changes the way processes appear in memory. It makes swap operations slower, and thus might not be desirable on systems which swap heavily. 55..33..44.. FFiillee ssyysstteemm IINNTTRRLLVVEE XX Allows interleaving of file systems across devices. See _i_n_t_r_l_v_e(4). MMPPXX__FFIILLSS XX Include code for the V7 multiplexer. The code is buggy and unsupported. UUCCBB__FFSSFFIIXX SS Ensure that file system updates are done in the correct order, thus making dam- aged file systems less likely and more easily repairable. TThhiiss ooppttiioonn iiss rreeqquuiirreedd bbyy UUCCBB__AAUUTTOOBBOOOOTT ((aaccttuuaallllyy,, bbyy tthhee --pp ooppttiioonn ooff _f_s_c_k((88)),, wwhhiicchh mmaakkeess cceerrttaaiinn aassssuummppttiioonnss aabboouutt tthhee ssttaattee ooff tthhee ffiillee ssyysstteemmss)).. UUCCBB__SSYYMMLLIINNKKSS CC Add a new inode type to the file system: the symbolic link. Symbolic links cause string substitution during the pathname interpretation process. See _l_n(1), _r_e_a_d_l_i_n_k(2), and _s_y_m_l_i_n_k(2). UUCCBB__NNKKBB SS Use file system blocks of _N KB, normally 1. Changes the fundamental file system unit from 512 byte blocks to 1024 byte blocks (with a corresponding reduction in the size of in-core inodes). This increases file system bandwidth by 100%. Note that UUCCBB__NNKKBB is not boolean, but is defined as 1 for 1KB blocks. Other val- ues are possible, but require additional macro definitions. All file systems would have to be remade with new ver- sions of _m_k_f_s and _r_e_s_t_o_r. AAllll ssuupppplliieedd ssooffttwwaarree eexxppeeccttss tthhiiss ooppttiioonn ttoo bbee eennaabblleedd.. UUCCBB__QQUUOOTTAASS CC Support a simplistic (and easily defeated) dynamic disk quota scheme. See _l_s(1), _p_q(1), _q_u_o_t_a(2), and _s_e_t_q_u_o_t_a(8). 17 March 1998 Installing/Operating 2.9BSD -42- Kernel configuration 55..33..55.. PPeerrffoorrmmaannccee MMoonniittoorriinngg DDIISSKKMMOONN CC Keep statistics on the buffer cache. They are printed by the -_b option of _i_o_s_t_a_t(8). UUCCBB__LLOOAADD DD Enable code that computes a Tenex style load average. See _l_a(1), _g_l_d_a_v(2), _l_o_a_d_a_v(3). UUCCBB__MMEETTEERR DD Keep statistics on memory, queue sizes, process states, interrupts, traps, and many other (possibly useful) things. See _v_m_s_t_a_t(1) and section 7.5 of this paper. 55..33..66.. DDeevviiccee DDrriivveerrss In this section, an XXXX__ prefix refers to the UNIX name of the device for which the option is intended to be enabled. For example, TTMM__IIOOCCTTLL refers to mag tape _i_o_c_t_ls in tm.c. Most of these definitions go in the header file _x_x_._h for the device. The exceptions are BBAADDSSEECCTT, MMAAXXBBAADD, UUCCBB__DDEEVVEERRRR, and UUCCBB__EECCCC. BBAADDSSEECCTT CC Enable bad-sector forwarding. Sectors marked bad by the disk formatter are transparently replaced when read or written. Currently, only the hk driver's code has been thoroughly tested. DDDDMMTT CC Currently used only by the tm driver. Should be defined if you have a TM-11 emulator which supports 800/1600 bpi dual density drives with software selec- tion. DDZZ__PPDDMMAA CC Configure the dz driver to do pseudo- dma. MMAAXXBBAADD CC This sets the maximum number of replace- ment sectors available on a disk sup- porting DEC standard bad sector forward- ing. It can be no larger than 126 but may be smaller to reduce the size of kernel data space. See the include file /_u_s_r/_i_n_c_l_u_d_e/_s_y_s/_d_k_b_a_d_._h. TTEEXXAASS__AAUUTTOOBBAAUUDD CC Support an _i_o_c_t_l which defeats detection of framing or parity errors. This is used by _g_e_t_t_y(8) to accurately guess a line's speed when a carriage return is 17 March 1998 Installing/Operating 2.9BSD -43- Kernel configuration typed. UUCCBB__DDEEVVEERRRR DD Print device error messages in a human readable (mnemonic) format. UUCCBB__EECCCC CC Recognize and correct soft ecc disk transfer errors. VVPP__TTWWOOSSCCOOMMPPLL CC Used in the Versatec (vp) driver. If defined, the byte count register will be loaded with the twos-complement of the byte count, rather than the byte count itself. Check your controller manual to see whether your controller requires this. XXXX__IIOOCCTTLL DD Turn on optional _i_o_c_t_ls for the corre- sponding device. See section 4 of the Berkeley PDP-11 UNIX Programmer's manual for details. XXXX__SSIILLOO DD Used in the dh and dz drivers. If defined, the drivers will use silo interrupts to avoid taking an interrupt for each character received. XXXX__SSOOFFTTCCAARR CC Currently used only by the dh and dz drivers. Should be defined if not all of the lines on a DH-11 or DZ-11 use modem control. It allows one to select lines on which modem control will be disabled. See _d_h(4) and _d_z(4). It can also be used with escape-code autodi- alers to allow modem control to be ignored while talking to the dialer. XXXX__TTIIMMEEOOUUTT DD Enable a watchdog timer. This is used to kick devices prone to losing inter- rupts. It is currently available only for the tm driver. 55..33..77.. MMiisscceellllaanneeoouuss SSyysstteemm CCaallllss UUCCBB__LLOOGGIINN CC Support a system call which can mark a process as a ``login process'' and set its recharge number (for accounting pur- poses). This is usually done by _l_o_g_i_n(1). See _l_o_g_i_n(2). UUCCBB__RREENNIICCEE DD Support a system call which allows a user to dynamically change a process's ``nice'' value over the entire range (-127 to 127) of values. See _r_e_n_i_c_e(1) 17 March 1998 Installing/Operating 2.9BSD -44- Kernel configuration and _r_e_n_i_c_e(2). UUCCBB__SSUUBBMM CC Support a system call to mark a process as having been ``submitted,'' permitting it to run after the user has logged out and enabling special accounting for its CPU use. See _s_u_b_m_i_t(1) and _s_u_b_m_i_t(2). If this option is enabled, _i_n_i_t(8) sends a SIGKILL signal to a user's unsubmitted processes when that user logs out. It is ineffective if MMEENNLLOO__JJCCLL is defined. 55..33..88.. PPeerrffoorrmmaannccee TTuunniinngg NNOOKKAA55 CC Simplify the code for kernel remapping by assuming that KDSA5 will not be used for normal kernel data. Kernel data space must end before 0120000 if this option is enabled. It is unfortunate but unavoidable that one must first make a kernel and size it to determine whether this option may be safely defined. It is usually possible on all but the largest separate I/D kernels, and on the small-to-medium nonseparate, overlaid kernels. The _c_h_e_c_k_s_y_s utility will print a warning message if the data limit is exceeded when a new kernel is loaded. PPRROOFFIILL CC Turn on system profiling. This requires a separate I/D cpu equipped with a KW11-P clock. It cannot be used on machines with ENABLE/34 boards since they have no spare page address regis- ters. If profiling is enabled, you should change the definition of SPLFIX in the corresponding machine Makefile to _:_s_p_l_f_i_x_._p_r_o_f_i_l. The directory /_u_s_r/_c_o_n_t_r_i_b/_g_e_t_s_y_s_p_r contains a program for extracting the profiling information from the kernel. UUCCBB__BBHHAASSHH DD Compile in code to hash buffer headers (and cut the time required by the _g_e_t_b_l_k routine by 50% or more on large sys- tems). UUCCBB__FFRRCCSSWWAAPP CC Force swaps on all forks and expands (but not vforks). This is used to transfer some of the load from a com- pute-bound CPU to an idle disk con- troller. This is probably not a good 17 March 1998 Installing/Operating 2.9BSD -45- Kernel configuration idea with VVIIRRUUSS__VVFFOORRKK defined, but then the load is better reduced by using vfork instead of fork. UUCCBB__IIHHAASSHH DD Compile in code to hash in-core inodes (and cut the time required by the _i_g_e_t routine by 50% or more on large sys- tems). UUNNFFAASSTT CC Do not use inline macro expansions designed to speed up file system accesses at the cost of a larger text segment. 55..44.. AAddddiittiioonnaall ccoonnffiigguurraattiioonn ddeettaaiillss A few of the parameters and options require a little care to set up; those considerations are discussed here. 55..44..11.. AAlltteerrnnaattee ddiisskk ddrriivveerrss There are several disk drivers provided for SMD disks. The hhpp driver supports RP04/05/06 disks; rrmm supports RM02/03 disks, and ddvvhhpp supports 300 Mbyte drives on Diva con- trollers. In addition, there is an xxpp driver which handles any of the above, plus RM05 disks, multiple controllers, and disks which are similar to those listed but with different geometry (e.g. Fujitsu 160 Mbyte drives). It can be used with UNIBUS or MASSBUS controllers or both. In general, if you have only one type of disk and one controller, the hhpp, rrmm or ddvvhhpp drivers are the best choices, since they are smaller and simpler. If you use the xxpp driver, it can be set up in one of two ways. If XXPP__PPRROOBBEE is defined in xp.h, the driver will attempt to determine the type of each disk and controller by probing and using the drive type register. To save the space occupied by this routine, or to specify different drive parameters, the drive and controller struc- tures can be initialized in ioconf.c if XXPP__PPRROOBBEE is not defined. The controller addresses will have to be initial- ized in either case (at least the first, if it is a boot device). The file /usr/include/sys/hpreg.h provides the definitions for the flags and sizes. Ioconf.c has an exam- ple of initialized structures. _X_p(4) gives more information about drive numbering, etc. 55..44..22.. DDiisskk mmoonniittoorriinngg ppaarraammeetteerrss The kernel is capable of maintaining statistics about disk activity for specified disks; this information can be printed by _i_o_s_t_a_t(8). This involves some setup, however, and if parameters are set incorrectly can cause the kernel monitoring routines to overrun their array bounds. To set this up correctly, choose the disks to be monitored. _I_o_s_t_a_t is configured for a maximum of 4 disks, but that could be 17 March 1998 Installing/Operating 2.9BSD -46- Kernel configuration changed by editing the headers. The drivers that do over- lapped seeks (hk, hp, rm and xp) use one field for each drive (N_X_X) plus one for the controller; the others use only one field, for the controller. When both drives and con- trollers are monitored, the drives come first, starting at _D_K_DKN, followed by the controller (or controllers, in the case of xp). Then set NNDDIISSKK in param.c to the desired num- ber. The number of the first slot to use for each driver is defined as _D_K_DKN in the device's header file, or is unde- fined if that driver is not using monitoring. _I_o_s_t_a_t cur- rently expects that if overlapped seeks are being metered, those disks are first in the array (i.e., DKN for that driver is 0). As an example, for 3 RP06 disks using the hp driver plus 1 RL02, HP_DKN should be 0, RL_DKN should be 4, and NNDDIISSKK should be 5 (3 hp disks + 1 hp controller + 1 rl). The complete correspondence for _i_o_s_t_a_t would then be: 0 (HP_DKN + 0) hp0 seeks 1 (HP_DKN + 1) hp1 seeks 2 (HP_DKN + 2) hp2 seeks 3 (HP_DKN + NHP) hp controller transfers 4 (RL_DKN + 0) rl transfers IItt iiss vveerryy iimmppoorrttaanntt tthhaatt NNDDIISSKK bbee llaarrggee eennoouugghh,, ssiinnccee tthhee ddrriivveerrss ddoo nnoott cchheecckk ffoorr oovveerrffllooww.. After the kernel disk monitoring is set up, _i_o_s_t_a_t itself needs to be edited to reflect the numbers and types of the disks. The source is in /usr/src/cmd. 55..44..33.. AAuuttoommaattiicc rreebboooott The automatic reboot facility (UUCCBB__AAUUTTOOBBOOOOTT) includes a number of components, several of which must know details of the boot configuration. The kernel has an integral boot routine, found in boot.s in the configuration directory for the machine, which reads in a block 0 bootstrap from the normal boot device and executes it. The block 0 bootstrap normally loads bboooott from the first file system on drive 0 of the disk; this can be changed if necessary. The second- stage bootstrap, /boot, needs to know where to find unix. The first step is to determine which kernel boot to use. Currently, there are boot modules supplied for the following disk types: hk, rl, rm, rp, dvhp, sc11 and sc21 (the last two are for Emulex SC11 and SC21 controllers, using the boot command). If one of these will work with your boot disk, place that entry in the bboooottddeevv field in the device configuration file before running _c_o_n_f_i_g, or simply copy ../conf/_d_kboot.s to boot.s in the machine configuration directory. If no boot module supplied will work, it is not too difficult to create one for your machine. The easiest 17 March 1998 Installing/Operating 2.9BSD -47- Kernel configuration way to do this is to copy one of the other boot modules, and modify the last section which actually reads the boot block. If you have a bootstrap ROM, you can simply jump to the cor- rect entry with any necessary addresses placed in registers first. Or, you can write a small routine to read in the first disk block. If you don't have a boot module, bboooottddeevv in the configuration file should be specified as nnoonnee, and noboot.s will be installed. This is a dummy file that keeps the load rules from changing. The UUCCBB__AAUUTTOOBBOOOOTT option should not be defined until a boot module is obtained. The other change that is normally required is to spec- ify where /unix will be found. This is done by changing the definition of RRBB__DDEEFFNNAAMMEE in /usr/include/sys/reboot.h. The definition is a string in the same format as the manual input to boot, for example "xp(0,0)unix". After making this change, boot will need to be recompiled (in /usr/src/sys/stand/bootstrap) and installed. It can be installed initially as /newboot, and the original boot can be used to load it for testing: >>bboooott _n_nBBoooott :: _d_k(0,0)newboot _n_nBBoooott :: _d_k(0,0)unix If you want to have core dumps made after crashes, this must be specified in the configuration file as well. Dumps are normally taken on the end of the swap device before rebooting, and after the system is back up and the file sys- tems are checked, the dump will be copied into /usr/sys by _s_a_v_e_c_o_r_e(8). Dump routines are available for the hk, hp, rm and xp drivers. To install, change the dduummppddeevv entry to the same value as the swap device. Then set dduummpplloo to a value that will allow as much as possible of memory to be saved. The dump routine will start the dump at dumplo and continue to the end of memory or the end of the swap device parti- tion, whichever comes first. Dumplo should be larger than swplo so that any early swaps will not overwrite the dump, but if possible, should be low enough that there is room for all of memory. The dduummpprroouuttiinnee entry in the configuration file is then set to _d_kdump, where _d_k is the disk type. Finally, after running _c_o_n_f_i_g, edit the header file _d_k.h in the new configuration directory to define _D_K_DUMP, so that that dump routine will be included when the driver is com- piled. 17 March 1998 Installing/Operating 2.9BSD -48- Kernel configuration 55..44..44.. CCoonnssiiddeerraattiioonnss oonn aa PPDDPP--1111//2233 If setting up a kernel on a PDP-11/23, it is necessary to consider the interrupt structure of the hardware. If there are any single-priority boards on the bus, they must be behind all multiple-priority devices. Otherwise, they may accept interrupts meant for another, higher-priority device farther from the processor, at a time when the system has set the processor priority to block the single-level device. The alternative is to use spl6 uniformly for any high processor priority (spl4, spl5, spl6). This may be accomplished by changing the _spl routines in mch.s, the definitions of br4 and br5 in l.s, and by changing the script :splfix.mtps (in the _c_o_n_f directory). Berkeley UNIX does not support more than 256K bytes of memory on the 11/23. If you have extra memory and a way to use it (e.g. a disk driver capable of 22-bit addressing) you will want to change this. 55..55.. CCoommppiilliinngg tthhee kkeerrnneell Once you have made any local changes, you are ready to compile the kernel. If you have made any changes which will affect the dependency rules in the Makefile, run ``make depend'' (the output of this command is best appreciated on a crt). Then, ``make unix.'' Note: although several short- cuts have been built into the makefile, the nonseparate I/D _m_a_k_e occasionally runs out of space while recompiling the kernel. If this happens, just restart it and it will gener- ally make it through the second time. The split I/D version of _m_a_k_e in /usr/70 should have no problem. Also note, it is imperative that overlaid kernels be compiled with the 2.9BSD versions of _c_c, _a_s (and _a_s_2) and _l_d. Use of older C prepro- cessors or assemblers will result in compile-time errors or (worse) systems that will almost run, but crash after a short time. After the unix binary is loaded, the makefile runs a small program called _c_h_e_c_k_s_y_s which checks for size over- flows. If you are building an overlaid system, check the size of the object file (see _s_i_z_e(1)) and overlay layout. The overlay structure may be changed by editing the make- file. For a non-separate I/D system, the base segment size must be between 8194 and 16382 bytes and each overlay must be at most 8192 bytes. The final object file ``unix'' should be copied to the root, and then booted to try it out. It is best to name it /newunix so as not to destroy the working system until you're sure it does work: ## cp unix /newunix ## sync It is also a good idea to keep the old system around under 17 March 1998 Installing/Operating 2.9BSD -49- Kernel configuration some other name. In particular, we recommend that you save the generic distribution version of the system permanently as /genericunix for use in emergencies. To boot the new version of the system you should follow the bootstrap procedures outlined in section 2.4 above. A systematic scheme for numbering and saving old versions of the system is best. You can repeat these steps whenever it is necessary to change the system configuration. 55..66.. MMaakkiinngg cchhaannggeess ttoo tthhee kkeerrnneell If you wish to make local mods to the kernel you should bracket them with #ifdef PICKLE ... #endif perhaps saving old code between #ifndef PICKLE ... #endif This will allow you to find changed code easily. To add a device not supported by the distribution sys- tem you will have to place the driver for the device in the directory /usr/src/sys/dev, edit a line into the block and/or character device table in /usr/src/sys/PICKLE/c.c, add the name of the device to the OPTIONAL line of the file Depend, and to the makefile load rules. Place the device's address and interrupt vector in the files ioconf.c and l.s respectively if it is not going to be configured by _a_u_t_o_c_o_n_f_i_g(8); otherwise, l.s will only need the normal interface to the C interrupt routine. If you use autocon- figuration, you will need an attach routine in the driver, and a probe routine in the driver or in _a_u_t_o_c_o_n_f_i_g. Use the entries for a similar device as an example. If the device driver uses the UNIBUS map or system buffers, it will proba- bly need modifications. Check ``Changes in the Kernel in 2.9BSD'' for more technical information regarding driver interfacing. You can then rebuild the system (be sure to make _d_e_p_e_n_d first). After rebooting the resulting kernel and making appropriate entries in the /dev directory, you can test out the new device and driver. Section 7.1 explains shutdown and reboot procedures. 17 March 1998 Installing/Operating 2.9BSD -50- Recompiling system software 66.. RREECCOOMMPPIILLIINNGG SSYYSSTTEEMM SSOOFFTTWWAARREE We now describe how to recompile system programs and install them. Some programs must be modified for the local system at this time, and other local changes may be desir- able now or later. Before any of these procedures are begun, be certain that the include files <whoami.h>, <sys/localopts.h> and <sys/param.h> are correct for the ker- nel that has been installed. This is important for commands that wish to know the name of the local machine or that size their data areas appropriately for the type of CPU. The general procedures are given first, followed by more detailed information about some of the major systems that require some setup. 66..11.. RReeccoommppiilliinngg aanndd rreeiinnssttaalllliinngg ssyysstteemm ssooffttwwaarree It is easy to regenerate the system, and it is a good idea to try rebuilding pieces of the system to build confi- dence in the procedures. The system consists of three major parts: the kernel itself, along with the bootstrap and stan- dalone utilities (/usr/src/sys), the user programs (/usr/src/cmd, /usr/src/ucb, and subdirectories), and the libraries (/usr/src/lib). The major part of this is /usr/src/cmd. We have already seen how to recompile the system itself. The commands and libraries can be recompiled in their respective source directories using the Makefile (or Ovmakefile if there are both overlaid and non-overlaid ver- sions). However, it is generally easier to use one of the MAKE scripts set up for /usr/src/lib, /usr/src/cmd, and /usr/src/ucb. These are used in a similar fashion, such as ## ./MAKE -40 [ -cp ] [ -f ] file ... The first, required flag sets the CPU class for which to compile. Three classes are used to used to set requirements for separate instruction and data and for floating point. ``MAKE -40'' makes nonseparate I/D versions that load the floating point interpreter as required. ``MAKE -34'' is similar but assumes a hardware floating point unit. ``MAKE -70'' is used for separate I/D machines and also assumes floating point hardware. ``MAKE -70 -f'' is used for sepa- rate I/D machines without floating point hardware. The use of these MAKE scripts automates the selection of CPU- dependent options and makes the optimal configuration of each program for the target computer. The optional argument -cp causes each program to be installed as it is made. They are installed in the normal directories, unless the environ- ment variable DESTDIR is set, in which case the normal path is prepended by DESTDIR. This can be used to compile and 17 March 1998 Installing/Operating 2.9BSD -51- Recompiling system software create a new set of binary directories, e.g. /nbsd/bin, /nbsd/lib, etc. Running the command ``MAKE -70 -cp *'' in /usr/src/lib, /usr/src/cmd and /usr/src/ucb would thus cre- ate a whole new tree of system binaries. The six major libraries are the C library in /usr/src/lib/c, the jobs library, /usr/src/lib/jobs, the FORTRAN libraries /usr/src/lib/libF77, /usr/src/lib/libI77, and /usr/src/lib/libU77, and the math library /usr/src/lib/m. Most libraries are made in two versions, one each for use with and without process overlays. In each case the library is remade by changing into /usr/src/lib and doing ## ./MAKE -_c_p_u _l_i_b_n_a_m_e or made and installed by ## ./MAKE -_c_p_u -cp _l_i_b_n_a_m_e Similar to the system, ## make clean cleans up in each subdirectory. To recompile individual commands, change to /usr/src/cmd or /usr/src/ucb, as appropriate, and use the MAKE script in the same way. Thus to compile adb, do ## ./MAKE -_c_p_u adb where cpu is 34, 40, or 70. To recompile everything, use ## ./MAKE -_c_p_u * After installing new binaries, you can use the script in /usr/src to link files together as necessary and to set all the right set-user-id bits. ## cd /usr/src ## ./MAKE aliases ## ./MAKE modes 66..22.. MMaakkiinngg llooccaall mmooddiiffiiccaattiioonnss To keep track of changes to system source we migrate changed versions of commands in /usr/src/cmd in through the directory /usr/src/new and out of /usr/src/cmd into /usr/src/old for a time before removing them. Locally writ- ten commands that aren't distributed are kept in /usr/src/local and their binaries are kept in /usr/local. This allows /usr/bin, /usr/ucb, and /bin to correspond to the distribution tape (and to the manuals that people can buy). People wishing to use /usr/local commands are made 17 March 1998 Installing/Operating 2.9BSD -52- Recompiling system software aware that they aren't in the base manual. As manual updates incorporate these commands they are moved to /usr/ucb. A directory /usr/junk to throw garbage into, as well as binary directories /usr/old and /usr/new are useful. The _m_a_n(1) command supports manual directories such as /usr/man/mann for new and /usr/man/manl for local to make this or something similar practical. 66..33.. SSeettttiinngg uupp tthhee mmaaiill ssyysstteemm The mail system can be set up in at least two ways. One strategy uses the _d_e_l_i_v_e_r_m_a_i_l(8) program to sort out network addresses according to the local network topology. It is not perfect, especially in the light of changing ARPAnet conventions. However, if you use the Berkeley net- work or are connected directly or indirectly to the ARPAnet, it is probably the method of choice for the time being. On the other hand, if you use only local mail and UUCP mail, /bin/mail (_m_a_i_l(1)) will suffice as a mail deliverer. In that case, you will only need to recompile _m_a_i_l(1) and _M_a_i_l(1). The entire mail system consists of the following com- mands: /bin/mail old standard mail program (from V7 or System III) /usr/ucb/Mail UCB mail program, described in Mail(1) /usr/lib/Mail.rc aliases and defaults for Mail(1) /etc/delivermail mail routing program /usr/net/bin/v6mail local mailman for berknet /usr/spool/mail mail spooling directory /usr/spool/secretmail secure mail directory /usr/bin/xsend secure mail sender /usr/bin/xget secure mail receiver /usr/lib/aliases mail forwarding information for delivermail /usr/ucb/newaliases command to rebuild binary forwarding database Mail is normally sent and received using the _M_a_i_l(1) com- mand, which provides a front-end to edit the messages sent and received, and passes the messages to _d_e_l_i_v_e_r_m_a_i_l(8) or _m_a_i_l(1) for routing and/or delivery. Mail is normally accessible in the directory /usr/spool/mail and is readable by all users.|- To send mail ----------- |- You can make your mail unreadable by others by changing the mode of the file /usr/spool/mail/_y_o_u_r_n_a_m_e to 600 and putting the line ``set keep'' in your .mailrc file. The directory /usr/spool/mail must not be writable 17 March 1998 Installing/Operating 2.9BSD -53- Recompiling system software which is secure against any possible perusal (except by a code-breaker) you should use the secret mail facility, which encrypts the mail so that no one can read it. 66..33..11.. SSeettttiinngg uupp mmaaiill aanndd MMaaiill Both /bin/mail and /usr/ucb/Mail should be recompiled to make local versions. Remake mail in /usr/src/cmd with the command ## ./MAKE -_c_p_u mail Install the new binary in /bin after testing; it must be setuserid root. Section 6.1 gives more details on the use of the MAKE scripts. To configure _M_a_i_l, change directories to /usr/src/ucb/Mail. Edit the file v7.local.h to assign a letter to your machine with the definition of LOCAL; if you do not have a local area network, the choice is arbitrary as long as you pick an unused letter. If you wish to use _d_e_l_i_v_e_r_m_a_i_l, the definition of SENDMAIL should be uncom- mented. Then add your machine to the table in config.c; configdefs.h gives some information on this. The network field should specify which networks (if any) you are con- nected to (note: the Schmidt net, SN, is Berknet). After the changes are made, move to /usr/src/ucb and ## ./MAKE -40 Mail (on a nonseparate I/D machine) or ## ./MAKE -70 Mail (on a separate I/D machine) Install _M_a_i_l in /usr/ucb; it should nnoott be setuserid. The Mail.rc file in /usr/lib can be used to set up limited dis- tribution lists or aliases if you are not using _d_e_l_i_v_e_r_m_a_i_l. 66..33..22.. SSeettttiinngg uupp ddeelliivveerrmmaaiill To set up the _d_e_l_i_v_e_r_m_a_i_l facility you should read the instructions in the file READ_ME in the directory /usr/src/ucb/delivermail and then adjust and recompile the _d_e_l_i_v_e_r_m_a_i_l program, installing it as /etc/delivermail. The routing algorithm uses knowledge of network name syntax built into its tables and aliasing and forwarding informa- tion built into the file /usr/lib/aliases to process each piece of mail. Local mail is delivered by giving it to the program /usr/net/bin/v6mail which adds it to the mailboxes in the directory /usr/spool/mail/_u_s_e_r_n_a_m_e, using a locking protocol to avoid problems with simultaneous updates. You should also set up the file /usr/lib/aliases for your installation, creating mail groups as appropriate. ----------- (mode 755) for this to work. 17 March 1998 Installing/Operating 2.9BSD -54- Recompiling system software 66..44.. SSeettttiinngg uupp aa uuuuccpp ccoonnnneeccttiioonn To connect two UNIX machines with a _u_u_c_p network link using modems, one site must have a automatic call unit and the other must have a dialup port. It is better if both sites have both. You should first read the paper in volume 2B of the UNIX Programmers Manual: ``Uucp Implementation Descrip- tion.'' It describes in detail the file formats and conven- tions, and will give you a little context. For any configu- ration, you must recompile all system dependent programs. Change directory to /usr/src/cmd/uucp and examine uucp.h, making any necessary changes. Recompile uucp with ``make'' and su to ``make install.'' You should ensure that the directories /usr/spool/uucp and /usr/spool/uucppublic exist. The former should be owned by uucp, mode 755 (or 777 is OK) and the latter should be mode 777 (and the home directory for login uucp). Periodically you should clean out /usr/spool/uucp and /usr/spool/uucppublic, as they can accumulate junk, espe- cially if you don't have a dialer. Run ``uulog'' once a day, and ``/usr/lib/uucp/uuclean'' periodically with appro- priate options to get rid of old stuff.|- You can also just remove some of the files in /usr/spool/uucp, but if you do this blindly you will cause some error messages to be gener- ated when uucp tries to access a file another file claims is there. (For instance, each mail transaction creates three files.) The /usr/spool/uucppublic directory is a place for people at other sites to send to when sending files to users on your machine. You should clean it out by hand when it gets excessive. If both sites have both a dialer and dialup: follow the directions in the volume 2B paper - this is the intended mode of operation and the directions fit well. You have to configure the following files in /usr/lib/uucp: L.sys setup all fields - this lists the other sites L-devices your dialer USERFILE permissions - this can be left alone You must also establish a login ``uucp'' in /etc/passwd with shell /usr/lib/uucp/uucico. Each site must know the other site's phone number, login, and password. ----------- |- The _c_r_o_n(8) program can arrange to execute these commands periodically. 17 March 1998 Installing/Operating 2.9BSD -55- Recompiling system software If you have only a dialup: you can be a second-class citizen on the uucp net. You must find another site that has a dialer, and have them poll you regularly. (Once a day is about the minimum that is reasonable.) When you send mail to another site, you must wait for them to call you. You must set up /usr/lib/uucp/USERFILE and /usr/lib/uucp/L.sys. Only the first 4 fields of L.sys are necessary, and in practice only the first field (site name) is looked at. A typical L.sys for a passive node might be: ucbvax Any _A_C_U 300 research Any _A_C_U 300 where the first field on each line is a site that will poll you and _A_C_U is either ``ACU'' or ``DIR.'' You need to put a password on the uucp login and let the other site know your phone number, uucp login name (which is usually uucp), and password. It doesn't matter whether they call you at 300 or 1200 baud. If you have a dialer and want to poll another site: normally, uucp will call the other site when it has anything to send it, and while it's at it will check to see if any- thing should come back. The command /usr/lib/uucp/uucico -r1 -sucbvax will force _u_u_c_p to poll ucbvax, even if there is nothing waiting. This command can be conveniently put in /usr/lib/crontab to run early each morning. If you are hav- ing trouble with the connection, invoke uucico by hand: /usr/lib/uucp/uucico -r1 -sucbvax -x7 where the --xx option turns on debugging output. The higher the number, the more debugging output you get; 1, 4, and 7 are reasonable choices. 66..55.. MMiisscceellllaanneeoouuss ssooffttwwaarree The directory /usr/contrib contains programs and pack- ages that you may wish to install on your system. Also, some programs or libraries in the _u_c_b directory are suffi- ciently unique to be noteworthy. Here is a brief summary. 66..55..11.. AAppee _A_p_e (_Arbitrary _Precision _Extended) is a replacement for the multiple precision arithmetic routines (_m_p(3)). It is much faster and contains numerous bug fixes. 17 March 1998 Installing/Operating 2.9BSD -56- Recompiling system software 66..55..22.. LL1111,, MM1111 _M_1_1 is a Macro-11 assembler. It recognizes and emu- lates almost all of the directives of standard DEC Macro-11 assemblers. _L_1_1 is its loader. 66..55..33.. JJoovvee _J_o_v_e (_Jonathan's _Own _Version of _EMACS) is an EMACS style editor developed at Lincoln Sudbury Regional High School. 66..55..44.. NNeewwss The network bulletin board system developed at Duke University and the University of North Carolina and since heavily modified at Berkeley. 66..55..55.. NNootteess The network bulletin board system developed at the Uni- versity of Illinois. This version contains many enhance- ments and clean _n_e_w_s interfaces. 66..55..66.. RRaannmm _R_a_n_m is a fast uniform pseudorandom number generator package developed at Berkeley. 17 March 1998 Installing/Operating 2.9BSD -57- System Operation 77.. SSYYSSTTEEMM OOPPEERRAATTIIOONN This section describes procedures used to operate a PDP-11 UNIX system. Procedures described here are used periodically, to reboot the system, analyze error messages from devices, do disk backups, monitor system performance, recompile system software and control local changes. 77..11.. BBoooottssttrraapp aanndd sshhuuttddoowwnn pprroocceedduurreess The system boot procedure varies with the hardware con- figuration, but generally uses the console emulator or a ROM routine to boot one of the disks. /boot comes up and prompts (with ``: '') for the name of the system to load. Simply hitting a carriage return will load the default sys- tem. The system will come up with a single-user shell on the console. To bring the system up to a multi-user config- uration from the single-user status, all you have to do is hit ^D on the console (you should check and, if necessary, set the date before going multiuser; see _d_a_t_e(1)). The sys- tem will then execute /etc/rc, a multi-user restart script, and come up on the terminals listed as active in the file /etc/ttys. See _i_n_i_t(8) and _t_t_y_s(5). Note, however, that this does not cause a file system check to be performed. Unless the system was taken down cleanly, you should run ``fsck -p'' or force a reboot with _r_e_b_o_o_t(8) to have the disks checked. In an automatic reboot, the system checks the disks and comes up multi-user without intervention at the console. If the file system check fails, or is interrupted (after it prints the date) from the console when a delete/rubout is hit, it will leave the system in special-session mode, allowing root to log in on one of a limited number of termi- nals (generally including a dialup) to repair file systems, etc. The system is then brought to normal multiuser opera- tions by signaling init with a SIGINT signal (with ``kill -INT 1''). To take the system down to a single user state you can use ## kill 1 or use the _s_h_u_t_d_o_w_n(8) command (which is much more polite if there are other users logged in) when you are up multi-user. Either command will kill all processes and give you a shell on the console, almost as if you had just booted. File sys- tems remain mounted after the system is taken single-user. If you wish to come up multi-user again, you should do this by: 17 March 1998 Installing/Operating 2.9BSD -58- System Operation ## cd / ## /etc/umount -a ## ^D The system can also be halted or rebooted with _r_e_b_o_o_t(8) if automatic reboots are enabled. Otherwise, the system is halted by switching to single-user mode to kill all pro- cesses, updating the disks with a ``sync'' command, and then halting. Each system shutdown, crash, processor halt and reboot is recorded in the file /usr/adm/shutdownlog with the cause. 77..22.. DDeevviiccee eerrrroorrss aanndd ddiiaaggnnoossttiiccss When errors occur on peripherals or in the system, the system prints a warning diagnostic on the console. These messages are collected regularly and written into a system error log file /usr/adm/messages by _d_m_e_s_g(8). Error messages printed by the devices in the system are described with the drivers for the devices in section 4 of the Berkeley PDP-11 UNIX Programmer's manual. If errors occur indicating hardware problems, you should contact your hardware support group or field service. It is a good idea to examine the error log file regularly (e.g. with ``tail -r /usr/adm/messages''). If you have DEC field service, they should know how to interpret these messages. If they do not, tell them to con- tact the DEC UNIX Engineering Group. 77..33.. FFiillee ssyysstteemm cchheecckkss,, bbaacckkuuppss aanndd ddiissaasstteerr rreeccoovveerryy Periodically (say every week or so in the absence of any problems) and always (usually automatically) after a crash, all the file systems should be checked for consis- tency by _f_s_c_k(8). The procedures of _b_o_o_t(8) or _r_e_b_o_o_t(8) should be used to get the system to a state where a file system check can be performed manually or automatically. Dumping of the file systems should be done regularly, since once the system is going it is easy to become compla- cent. Complete and incremental dumps are easily done with _d_u_m_p(8). You should arrange to do a towers-of-Hanoi dump sequence; we tune ours so that almost all files are dumped on two tapes and kept for at least a week in almost every case. We take full dumps every month (and keep these indef- initely). Dumping of files by name is best done by _t_a_r(1) but the amount of data that can be moved in this way is limited to a single tape. Finally, if there are enough drives, entire disks can be copied with _d_d(1) using the raw special files 17 March 1998 Installing/Operating 2.9BSD -59- System Operation and an appropriate block size. It is desirable that full dumps of the root file system are made regularly. This is especially true when only one disk is available. Then, if the root file system is damaged by a hardware or software failure, you can rebuild a work- able disk using a standalone restore in the same way that _r_e_s_t_o_r was used to build the initial root file system. Exhaustion of user-file space is certain to occur now and then; the only mechanisms for controlling this phe- nomenon are occasional use of _d_f(1), _d_u(1), _q_u_o_t(8), threat- ening messages of the day, personal letters, and (probably as a last resort) quotas (see _s_e_t_q_u_o_t_a(8)). 77..44.. MMoovviinngg ffiillee ssyysstteemm ddaattaa If you have the equipment, the best way to move a file system is to dump it to magtape using _d_u_m_p(8), to use _m_k_f_s(8) to create the new file system, and restore, using _r_e_s_t_o_r(8), the tape. If for some reason you don't want to use magtape, dump accepts an argument telling where to put the dump; you might use another disk. Sometimes a file sys- tem has to be increased in logical size without copying. The super-block of the device has a word giving the highest address that can be allocated. For small increases, this word can be patched using the debugger _a_d_b(1) and the free list reconstructed using _f_s_c_k(8). The size should not be increased greatly by this technique, since the file system will then be short of inode slots. Read and understand the description given in _f_i_l_s_y_s(5) before playing around in this way. If you have to merge a file system into another, exist- ing one, the best bet is to use _t_a_r(1). If you must shrink a file system, the best bet is to dump the original and restor it onto the new file system. However, this will not work if the i-list on the smaller file system is smaller than the maximum allocated inode on the larger. If this is the case, reconstruct the file system from scratch on another file system (perhaps using _t_a_r(1)) and then dump it. If you are playing with the root file system and only have one drive the procedure is more complicated. What you do is the following: 1. GET A SECOND PACK!!!! 2. Dump the root file system to tape using _d_u_m_p(8). 3. Bring the system down and mount the new pack. 4. Load the standalone versions of _m_k_f_s(8) and _r_e_s_t_o_r(8) as in sections 2.1-2.3 above. 17 March 1998 Installing/Operating 2.9BSD -60- System Operation 5. Boot normally using the newly created disk file system. Note that if you add new disk drivers they should also be added to the standalone system in /usr/src/sys/stand. 77..55.. MMoonniittoorriinngg SSyysstteemm PPeerrffoorrmmaannccee The _i_o_s_t_a_t(8) and _v_m_s_t_a_t(8) programs provided with the system are designed to aid in monitoring systemwide activ- ity. By running them when the system is active you can judge the system activity in several dimensions: job distri- bution, virtual memory load, swapping activity, disk and CPU utilization. Ideally, there should be few blocked (DW) jobs, there should be little swapping activity, there should be available bandwidth on the disk devices (most single arms peak out at 30-35 tps in practice), and the user CPU uti- lization (US) should be high (above 60%). If the system is busy, then the count of active jobs may be large, and several of these jobs may often be blocked (DW). If you run _v_m_s_t_a_t when the system is busy (a ``vmstat 5'' gives all the numbers computed by the system), you can find imbalances by noting abnormal job distributions. If many processes are blocked (DW), then the disk subsystem is overloaded or imbalanced. If you have several non-DMA devices or open teletype lines that are ``ringing'', or user programs that are doing high-speed non-buffered input/output, then the system time may go high (60-70% or higher). It is often possible to pin down the cause of high system time by looking to see if there is excessive context switching (CS), interrupt activity (IN) or system call activity (SY). If the system is heavily loaded, or if you have little memory for your load (248K is little in almost any case), then the system will be forced to swap. This is likely to be accompanied by a noticeable reduction in system perfor- mance and pregnant pauses when interactive jobs such as edi- tors swap out. If you expect to be in a memory-poor envi- ronment for an extended period you might consider adminis- tratively limiting system load. 77..66.. AAddddiinngg uusseerrss New users can be added to the system by adding a line to the password file /etc/passwd. You should add accounts for the initial user community, giving each a directory and a password, and putting users who will wish to share soft- ware in the same group. User id's should be assigned start- ing with 16 or higher, as lower id's are treated specially by the system. Default startup files should probably pro- vided for new users and can be copied from /usr/public. 17 March 1998 Installing/Operating 2.9BSD -61- System Operation Initial passwords should be set also. A number of guest accounts have been provided on the distribution system; these accounts are for people at Berke- ley and at Bell Laboratories who have done major work on UNIX in the past. You can delete these accounts, or leave them on the system if you expect that these people would have occasion to login as guests on your system. 77..77.. AAccccoouunnttiinngg UNIX currently optionally records two kinds of account- ing information: connect time accounting and process resource accounting. The connect time accounting informa- tion is normally stored in the file /usr/adm/wtmp, which is summarized by the program _a_c(8). The process time account- ing information is stored in the file /usr/adm/acct, and analyzed and summarized by the program _s_a(8). If you need to implement recharge for computing time, you can implement procedures based on the information pro- vided by these commands. A convenient way to do this is to give commands to the clock daemon /etc/cron to be executed every day at a specified time. This is done by adding lines to /usr/adm/crontab; see _c_r_o_n(8) for details. 77..88.. RReessoouurrccee ccoonnttrrooll Resource control in the current version of UNIX is rather primitive. Disk space usage can be monitored by _d_u(1) or _q_u_o_t(8) as was previously mentioned. Disk quotas can be set and changed with _s_e_t_q_u_o_t_a(8) if the kernel has been configured for quotas. Our quota mechanism is simplis- tic and easily defeated but does make users more aware of the amount of space they use. 77..99.. FFiilleess wwhhiicchh nneeeedd ppeerriiooddiicc aatttteennttiioonn We conclude the discussion of system operations by listing the files and directories that continue to grow and thus require periodic truncation, along with references to relevant manual pages. _C_r_o_n(8) can be used to run scripts to truncate these periodically, possibly summarizing first or saving recent entries. Some of these can be disabled if you don't need to collect the information. //uussrr//aaddmm//aacccctt sa(8) raw process account data //uussrr//aaddmm//mmeessssaaggeess dmesg(8) system error log //uussrr//aaddmm//sshhuuttddoowwnnlloogg shutdown(8) log of system reboots //uussrr//aaddmm//wwttmmpp ac(8) login session accounting //uussrr//ssppooooll//uuuuccpp//LLOOGGFFIILLEE uulog(1) uucp log file //uussrr//ssppooooll//uuuuccpp//SSYYSSLLOOGG uulog(1) more uucp logging //uussrr//ddiicctt//ssppeellllhhiisstt spell(1) spell log 17 March 1998 Installing/Operating 2.9BSD -62- System Operation //uussrr//lliibb//lleeaarrnn//lloogg learn(1) learn lesson logging //uussrr//ssyyss savecore(8) system core images 17 March 1998 Installing/Operating 2.9BSD -63- Magic numbers 88.. KKEERRNNEELL MMAAGGIICC NNUUMMBBEERRSS This sections contains a collection of magic numbers for use in patching core or an executable unix binary. Some of them have also been mentioned earlier in this paper. With the exception of the _x_p___t_y_p_e_[_i_] variables (which hold bytes) and _s_w_p_l_o (which is a long) all locations given con- tain short integers. N.B.: in the case of paired interrupt vectors (for DHs and DZs) the address of the second vector of the pair is four more than the address of the first vec- tor. Interrupt Vectors Vector Handler Contents Block device Character device 0160 rlio 01202 8 18 0210 hkio 01142 4 19 0220 rkio 01172 0 9 0224 tmio 01222 3 12 0224 htio 01152 7 15 0224 tsio 01232 9 20 0254 xpio 01242 6 14 0260 rpio 01212 1 11 |- dzin 01132 - 21 |- dzdma 02202 - 21 |- dhin 01112 - 4 |- dhou 01122 - 4 |- lpio 01162 - 2 ----------- |- Set by _a_u_t_o_c_o_n_f_i_g(8). 17 March 1998 Installing/Operating 2.9BSD -64- Magic numbers Other Variables Name Address Contents xp_addr 061464 0176700 xp_type[0] 061472 |= xp_type[1] 061506 |= xp_type[2] 061522 |= xp_type[3] 061536 |= HKADDR 061006 0177440 HTADDR 0114236 |- RKADDR 061152 0177400 RLADDR 061154 0174400 RPADDR 061236 0176710 TMADDR 0113330 |- TSADDR 0113622 |- dz_addr 0113324 |- dh_addr 0114146 |- lp_addr 0113462 |- rootdev 060772 * pipedev 060776 * swapdev 060774 * swplo 061000 * nswap 061004 * ----------- |- Set by _a_u_t_o_c_o_n_f_i_g(8). |= Set by reading the corresponding drive type reg- ister. * System dependent. 17 March 1998