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 Installing and Operating 4.1bsd 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 configure 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 system operations procedures: shutdown and startup, hardware error reporting and diagnosis, file system backup procedures, resource control, performance 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 system; because of the many changes and additions throughout the system, it would require a substantial effort to merge into most earlier systems.
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 modifications 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 (tar format is best, or V7 dump if the file system configuration will be the same). A new root file system can be made and read in using standalone 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.
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**:
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 programs, a dump image of a root file system, and a tar image of part of the /usr file system. The files on this tape are:
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:
There is also a generic disk driver, xp, that will handle most types of SMD disks on one or more controllers (even different types on the same controller). The xp driver handles 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:
Large UNIX physical disks (hk, rp, xp) are divided into 8 logical disk partitions, each of which may occupy any consecutive cylinder range on the physical device. The cylinders occupied by the 8 partitions for each drive type are specified in section 4 of the Berkeley PDP-11 UNIX Programmer'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 ``xx(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 available 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 0th partition being ``hk0a''). Finally, ``5940'' is the sector offset to partition 1, as determined from the manual page hk(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 thousand UNIX files.
UNIX makes a distinction between ``block'' and ``character'' (raw) devices. Each disk has a block device interface where the system makes the device byte addressable and you can write a single byte in the middle of the disk. The system will read out the data from the disk sector, insert the byte you gave it and put the modified data back. The disks with the names ``/dev/xx0a'', etc. are block devices and thus use the system's normal buffering mechanism. There are also raw devices available, which do physical I/O operations directly from the program's data area. These have names like ``/dev/rxx0a'', 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 (mounting) a UNIX file system residing on a given block device with a directory in the current name space. See mount(2) and mount(8). This association is severed by umount.
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.
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:
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 procedure 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 magnetic tape. The 2.9BSD file system uses 1K-byte blocks by clustering disk blocks (as did the 2.8BSD system); file systems in other formats cannot be mounted. Those upgrading from 2.8 should note that 2.9BSD uses generally different file system partition sizes than 2.8BSD, and that a few of the major device numbers have changed (in particular, that for the hk). 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, 512restor(8) can restore old format V7 dump image tapes into the file system format used by 2.9BSD. Tar(1) can also be used to exchange files from different file system formats, and has the additional advantage that directory trees can be placed on different file systems than on the old configuration. Note that 2.9BSD does not support cpio tape format.
The tape bootstrap procedure involves three steps: loading the tape bootstrap monitor, creating and initializing a UNIX ``root'' file system system on the disk, and booting the system.
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):
The console should type
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 cat 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 dk and the tape type for tp. In response to the prompt of the bootstrap which is now running, type
Now create the root file system using the following procedures. First determine the size of your root file system from the following table:
If the disk on which you are creating a root file system is an xp disk, you should check the drive type register at this time to make sure it holds a value that will be recognized correctly by the driver. There are numbering conflicts; the following numbers are used internally:
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.
Then run a standalone version of the mkfs (8) program. In the following procedure, substitute the correct types for tp and dk and the size determined above for size:
To restore a small root file system onto it, type
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:
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 system release number, and applies only to the operating system kernel.
Next the mem 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 autoconfig(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 /.profile 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 Programmer'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 unix on the root file system, one for each possible type of root file system device. All but one of them (xpunix) has had its symbol table removed (i.e. they have been ``stripped''; see strip(1)). The unstripped copy is linked (see ln(1)) to /unix to provide a system namelist for programs like ps(1) and autoconfig(8). All of the systems were created from /unix by the C shell script /genallsys.sh. If you had to patch the xp type as you booted, you may want to use adb (see adb(1)) to make the same patch in a copy of xpunix. If you are short of space, you can patch a copy of /unix instead (setting the rootdev, etc.) and install it as /unix after verifying that it works. See /genallsys.sh for examples of using adb to patch the system. The system load images for other disk types can be removed. Do not remove or replace the copy of /unix, however, unless you have made a working copy of it that is patched for your file system configuration and still has a symbol table. Many programs use the symbol table of /unix in order to determine the locations of things in memory, therefore /unix should always be an unstripped file corresponding to the current system. If at all possible, you should save the original UNIX binaries for your disk configuration (dkunix and unix) for use 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:
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 bootstraps 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 dd(1) to copy the right boot block onto the disk; the first form of the command is for small disks (rk, rl) and the second form for disks with multiple partitions (hk, rp, xp), substituting as usual for dk:
Before continuing, check the integrity of the root file system by giving the command
If there are inconsistencies in the file system, you may be prompted
to apply corrective action; see the document describing
The number of free blocks will vary depending on the disk you are
using for your root file system.
This section will describe ways in which the file systems 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 /dev directory, with special files for each peripheral device, and the tables in /etc 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 configuration should be chosen before the rest of the distribution tape is read onto disk to minimize the work of reconfiguration.
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 section (3.1) are optional.
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 (c) 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 specified in the ioconf.c file for each system, and may be changed if necessary. The last partition (h) always describes the entire disk, and can be used for disk-to-disk copies.
Warning: for disks on which DEC standard 144 bad sector forwarding is supported, the last track and up to 126 preceeding sectors contain replacement sectors and bad sector lists. Disk-to-disk copies should be careful to avoid overwriting this information. See bad144(8). Bad sector forwarding is optional in the hk, hp, rm, and xp drivers. It has been only lightly tested in the latter three cases.
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 table are the partitions of each drive devoted to the root file system and the swapping area.
Each disk also has a swapping area and a root file system. 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 must divide by 2 to use 5000 when specifying the size to the mkfs command. The sizes and offsets in the kernel (ioconf.c) and the manual pages are in 512-byte blocks. If bad sector forwarding is supported for your disk, be sure to leave sufficient room to contain the bad sector information when making new file systems.
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 editor, 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 partition) file system on another disk. On RK06 and RK07 systems, where there is little space in the hk?c or hk?d file 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 several disk arms. There are at least five components of the disk load that you can divide between the available 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 containing 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, rm0, we will put the root file system in rm0a, and the /usr file system in rm0c, which has enough space to hold it and then some. If we had only one RM03, we would put user files in the rm0c partition with the system source and binaries, or split them between rm0d and rm0e. 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 rm1c and put user files there, calling the file system /mnt. We would keep a backup copy of the root file system in the rm1a disk partition, a file system for /tmp on rm0b, and swap on rm1b.
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 mkfs(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 mounted before any I/O through pipes is attempted).
Devices are accessed through special files in the file system, made by the mknod(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 mknod. 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. dh, lp, xp). 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 swap (or, if swap is after a file system as on RK05 or RL disks, link the other node to swap). Different devices are specified to MAKE in various ways. Terminal multiplexors (DZ and DH) are specified by boards, 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 hp, rm and xp 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 ht, tm and ts, as above, and also ut, 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 ht0 or ut0 will result in nodes mt0 and mt1 (800 and 1600 bpi, respectively) and parallel nodes for other options; ht1 uses the names mt2 and mt3. See ht(4) and tm(4). In contrast, the MAKE script makes only one set of nodes for tm or ts, 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 formatter you would do:
You can then do
There are a number of small files in /etc that are used by various programs to determine things about the local configuration. 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 presented here for organization. Both /etc/dtab and /etc/fstab should be edited now.
This file contains the list of devices which will be checked at boot time by autoconfig(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, autoconfig 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 system. 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 commented out with a '#' at the beginning of the line. The format of the entries is defined in dtab(5). Autoconfig(8) describes the autoconfiguration process. One word of caution: if a device fails to interrupt as expected, and if its unit number is specified (not a '?' wildcard), autoconfig will notify the driver that the device is not present, and preconfigured devices (like root disks) could be disconnected. 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.
This file contains the list of file systems normally mounted on the system. Its format is defined in fstab(5). Programs like df(1) and fsck(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.
The banner printed by getty(8) is read from /etc/ident. Edit this file to the banner you wish to use. It may contain special characters to clear terminal screens, etc., but note that the same file is used for all terminals.
The contents of /etc/motd, the ``message of the day,'' is displayed at the terminal when a user is logged in by login(1).
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 contain asterisks.
As the system begins multiuser operations, it executes the commands in /etc/rc (see init(8)). Most of the commands in this file are standard and should not be changed, including 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
If UNIX is to support simultaneous access from more than just the console terminal, the file /etc/ttys (ttys(5)) has to be edited.
Terminals connected via DZ interfaces are conventionally named ttydd where dd 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 conventionally named ttyhx, where x is a hexadecimal digit. If more than one DH interface is present in a configuration, successive terminals would be named ttyix, ttyjx, 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 init(8)).
The second character of each line in the /etc/ttys file lists the speed and initial parameter settings for the terminal. The most common choices, from getty(8), are:
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 dh(4) and dz(4) for details.
You should also edit the file /etc/ttytype placing the type of each terminal there (see ttytype(5)).
When the system starts running multi-user, all terminals that are listed in /etc/ttys having a 1 or 3 as the first character of their line are enabled. If, during normal 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 init process, by typing (see kill(1))
Note that if a special file is inaccessible when init 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.
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.
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 bin, include, lib, and ucb subdirectories are essential. The system sources will also be needed to reconfigure the kernel; they are in /usr/src/sys. The adm, dict, msgs, preserve, spool, sys and tmp directories may also be extracted to provide a skeletal system. The first part of this section describes how to extract /usr as part of a full bootstrap; 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.
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
disk throughout this section.
You may want to create a small ``prototype'' file to describe
the file system (see
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 (occupying 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
mkfs, use its name for proto below.
The prototype file needs to contain only the name of the bootstrap,
the sizes, and the line for the root directory (don't forget the '$' to
Look up the correct size for this file system in the manual section
for the disk.
Note that the size given to mkfs is in file system blocks
of 1024 bytes, and thus the sizes in the manual page will have to be divided
If not using a prototype file,
substitute the size for proto 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 ( ); don't type these.
Then execute the following commands (substituting rmt1 and nrmt1
for rmt0 and nrmt0 respectively if you have a 1600 bpi tape on an
ht or tm controller):
You can now check the consistency of the /usr file system by doing
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.
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 kernel 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 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:
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.
This section describes procedures used to set up a PDP-11 UNIX kernel (operating system). It explains the layout 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.
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 configuration. It is in this directory, /usr/src/sys/machine, that the kernel is compiled.
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 config(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 correspond 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 config to create a system directory ../PICKLE with ``config PICKLE.'' Note the difference between config and autoconfig. Config 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. Autoconfig adapts the running kernel to the hardware actually present, by testing and setting the register addresses and interrupt vectors.
Config does most of the work of configuration, but local needs will dictate some changes in the options and 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 specific 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 autoconfig(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 extensive information on the autoreboot and disk monitoring setup. After verifying that those features are configured correctly for your system, you can proceed to kernel compilation.
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 following each will be used to mark the options throughout the rest of this section.
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 MAXMEM, 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 UCB_NKB, which is unlikely to change. Each option is marked with a letter to indicate into which of the four categories above it falls.
In this section, an XX_ prefix refers to the UNIX name of the device for which the option is intended to be enabled. For example, TM_IOCTL refers to mag tape ioctls in tm.c. Most of these definitions go in the header file xx.h for the device. The exceptions are BADSECT, MAXBAD, UCB_DEVERR, and UCB_ECC.
A few of the parameters and options require a little care to set up; those considerations are discussed here.
There are several disk drivers provided for SMD disks. The hp driver supports RP04/05/06 disks; rm supports RM02/03 disks, and dvhp supports 300 Mbyte drives on Diva controllers. In addition, there is an xp 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 hp, rm or dvhp drivers are the best choices, since they are smaller and simpler. If you use the xp driver, it can be set up in one of two ways. If XP_PROBE 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 structures can be initialized in ioconf.c if XP_PROBE is not defined. The controller addresses will have to be initialized 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 example of initialized structures. Xp(4) gives more information about drive numbering, etc.
The kernel is capable of maintaining statistics about disk activity for specified disks; this information can be printed by iostat(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. Iostat is configured for a maximum of 4 disks, but that could be changed by editing the headers. The drivers that do overlapped seeks (hk, hp, rm and xp) use one field for each drive (NXX) plus one for the controller; the others use only one field, for the controller. When both drives and controllers are monitored, the drives come first, starting at DK_DKN, followed by the controller (or controllers, in the case of xp). Then set NDISK in param.c to the desired number. The number of the first slot to use for each driver is defined as DK_DKN in the device's header file, or is undefined if that driver is not using monitoring. Iostat currently 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 NDISK should be 5 (3 hp disks + 1 hp controller + 1 rl). The complete correspondence for iostat would then be:
After the kernel disk monitoring is set up, iostat itself needs to be edited to reflect the numbers and types of the disks. The source is in /usr/src/cmd.
The automatic reboot facility (UCB_AUTOBOOT) 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 boot 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 bootdev field in the device configuration file before running config, or simply copy ../conf/dkboot.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 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 correct 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, bootdev in the configuration file should be specified as none, and noboot.s will be installed. This is a dummy file that keeps the load rules from changing. The UCB_AUTOBOOT option should not be defined until a boot module is obtained.
The other change that is normally required is to specify where /unix will be found. This is done by changing the definition of RB_DEFNAME 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:
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 systems are checked, the dump will be copied into /usr/sys by savecore(8). Dump routines are available for the hk, hp, rm and xp drivers. To install, change the dumpdev entry to the same value as the swap device. Then set dumplo 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 partition, 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 dumproutine entry in the configuration file is then set to dkdump, where dk is the disk type. Finally, after running config, edit the header file dk.h in the new configuration directory to define DK_DUMP, so that that dump routine will be included when the driver is compiled.
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 conf 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.
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 shortcuts have been built into the makefile, the nonseparate I/D make occasionally runs out of space while recompiling the kernel. If this happens, just restart it and it will generally make it through the second time. The split I/D version of make in /usr/70 should have no problem. Also note, it is imperative that overlaid kernels be compiled with the 2.9BSD versions of cc, as (and as2) and ld. Use of older C preprocessors 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 checksys which checks for size overflows. If you are building an overlaid system, check the size of the object file (see size(1)) and overlay layout. The overlay structure may be changed by editing the makefile. 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:
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.
If you wish to make local mods to the kernel you should bracket them with
To add a device not supported by the distribution system 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
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
otherwise, l.s will only need the normal interface to the C interrupt routine.
If you use autoconfiguration, you will need an attach routine in the driver,
and a probe routine in the driver or in autoconfig.
Use the entries for a similar device as an example.
If the device driver uses the UNIBUS map or system buffers,
it will probably 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 depend first).
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.
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 desirable 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 kernel 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.
It is easy to regenerate the system, and it is a good idea to try rebuilding pieces of the system to build confidence in the procedures. The system consists of three major parts: the kernel itself, along with the bootstrap and standalone 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 versions). 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
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
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 written 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 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 man(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.
The mail system can be set up in at least two ways. One strategy uses the delivermail(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 network 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 (mail(1)) will suffice as a mail deliverer. In that case, you will only need to recompile mail(1) and Mail(1).
The entire mail system consists of the following commands:
Mail is normally accessible in the directory /usr/spool/mail and is readable by all users.** To send mail 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.
Both /bin/mail and /usr/ucb/Mail should be recompiled to make local versions. Remake mail in /usr/src/cmd with the command
To set up the delivermail facility you should read the instructions in the file READ_ME in the directory /usr/src/ucb/delivermail and then adjust and recompile the delivermail program, installing it as /etc/delivermail. The routing algorithm uses knowledge of network name syntax built into its tables and aliasing and forwarding information 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/username, 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.
To connect two UNIX machines with a uucp 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 Description.'' It describes in detail the file formats and conventions, and will give you a little context. For any configuration, 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, especially if you don't have a dialer. Run ``uulog'' once a day, and ``/usr/lib/uucp/uuclean'' periodically with appropriate 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 generated 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:
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:
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 anything should come back. The command
The directory /usr/contrib contains programs and packages that you may wish to install on your system. Also, some programs or libraries in the ucb directory are sufficiently unique to be noteworthy. Here is a brief summary.
Ape (Arbitrary Precision Extended) is a replacement for the multiple precision arithmetic routines (mp(3)). It is much faster and contains numerous bug fixes.
M11 is a Macro-11 assembler. It recognizes and emulates almost all of the directives of standard DEC Macro-11 assemblers. L11 is its loader.
Jove (Jonathan's Own Version of EMACS) is an EMACS style editor developed at Lincoln Sudbury Regional High School.
The network bulletin board system developed at Duke University and the University of North Carolina and since heavily modified at Berkeley.
The network bulletin board system developed at the University of Illinois. This version contains many enhancements and clean news interfaces.
Ranm is a fast uniform pseudorandom number generator package
developed at Berkeley.
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.
The system boot procedure varies with the hardware configuration, 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 system. The system will come up with a single-user shell on the console. To bring the system up to a multi-user configuration 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 date(1)). The system 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 init(8) and ttys(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 reboot(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 terminals (generally including a dialup) to repair file systems, etc. The system is then brought to normal multiuser operations by signaling init with a SIGINT signal (with ``kill -INT 1'').
To take the system down to a single user state you can use
Each system shutdown, crash, processor halt and reboot is recorded in the file /usr/adm/shutdownlog with the cause.
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 dmesg(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 contact the DEC UNIX Engineering Group.
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 consistency by fsck(8). The procedures of boot(8) or reboot(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 complacent. Complete and incremental dumps are easily done with dump(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 indefinitely).
Dumping of files by name is best done by tar(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 dd(1) using the raw special files 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 workable disk using a standalone restore in the same way that restor 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 phenomenon are occasional use of df(1), du(1), quot(8), threatening messages of the day, personal letters, and (probably as a last resort) quotas (see setquota(8)).
If you have the equipment, the best way to move a file system is to dump it to magtape using dump(8), to use mkfs(8) to create the new file system, and restore, using restor(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 system 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 adb(1) and the free list reconstructed using fsck(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 filsys(5) before playing around in this way.
If you have to merge a file system into another, existing one, the best bet is to use tar(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 tar(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:
Note that if you add new disk drivers they should also be added to the standalone system in /usr/src/sys/stand.
The iostat(8) and vmstat(8) programs provided with the system are designed to aid in monitoring systemwide activity. By running them when the system is active you can judge the system activity in several dimensions: job distribution, 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 utilization (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 vmstat 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 performance and pregnant pauses when interactive jobs such as editors swap out. If you expect to be in a memory-poor environment for an extended period you might consider administratively limiting system load.
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 software in the same group. User id's should be assigned starting with 16 or higher, as lower id's are treated specially by the system. Default startup files should probably provided for new users and can be copied from /usr/public. Initial passwords should be set also.
A number of guest accounts have been provided on the distribution system; these accounts are for people at Berkeley 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.
UNIX currently optionally records two kinds of accounting information: connect time accounting and process resource accounting. The connect time accounting information is normally stored in the file /usr/adm/wtmp, which is summarized by the program ac(8). The process time accounting information is stored in the file /usr/adm/acct, and analyzed and summarized by the program sa(8).
If you need to implement recharge for computing time, you can implement procedures based on the information provided 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 cron(8) for details.
Resource control in the current version of UNIX is rather primitive. Disk space usage can be monitored by du(1) or quot(8) as was previously mentioned. Disk quotas can be set and changed with setquota(8) if the kernel has been configured for quotas. Our quota mechanism is simplistic and easily defeated but does make users more aware of the amount of space they use.
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. Cron(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.
/usr/adm/acct sa(8) raw process account data /usr/adm/messages dmesg(8) system error log /usr/adm/shutdownlog shutdown(8) log of system reboots /usr/adm/wtmp ac(8) login session accounting /usr/spool/uucp/LOGFILE uulog(1) uucp log file /usr/spool/uucp/SYSLOG uulog(1) more uucp logging /usr/dict/spellhist spell(1) spell log /usr/lib/learn/log learn(1) learn lesson logging /usr/sys savecore(8) system core images
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 xp_type[i] variables (which hold bytes) and swplo (which is a long) all locations given contain 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 vector.
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
Other Variables Name Address Contents xp_addr 061464 0176700 xp_type 061472 = xp_type 061506 = xp_type 061522 = xp_type 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 *
**DEC, MASSBUS, PDP, and UNIBUS are trademarks of Digital Equipment Corporation.
***UNIX is a trademark of Bell Laboratories.
** Other controllers and drives may be easily usable with the system, but might require minor modifications to the system to allow bootstrapping. The controllers and the drives shown here are known to work as bootstrap devices.
**References of the form X(Y) mean the subsection named X in section Y of the Berkeley PDP-11 UNIX Programmer's manual.
**It is possible to change the partitions by changing the values in the disk's sizes array in ioconf.c.
**These sizes are for full disks less some space used for swapping.
**ENABLE/34 is a trademark of Able Computer, Inc.
** You can make your mail unreadable by others by changing the mode of the file /usr/spool/mail/yourname to 600 and putting the line ``set keep'' in your .mailrc file. The directory /usr/spool/mail must not be writable (mode 755) for this to work.
** The cron(8) program can arrange to execute these commands periodically.
** Set by autoconfig(8).
** Set by autoconfig(8).
*** Set by reading the corresponding drive type register.
* System dependent.