.TL
Installing
Perkin-Elmer
UNIX
.AU
* Richard Miller
.AI
University of Wollongong
.PP
.FS
* Most of this document is plagiarised from
.I
Setting Up UNIX \- Seventh Edition
by C.B. Haley and D.M. Ritchie.
.FE
The distribution tape is 9-track 800 BPI and contains the following files,
separated by tapemarks:
.DS
.ta 6
File 0:   (80-byte records)
	UNIX \fIboot\fR(8) program, loadable by "50 Sequence"
File 1:   (256-byte records)
	UNIX \fIboot\fR(8) program, loadable by LSU
File 2:   (512-byte records)
	Standalone \fImkfs\fR(1) program
File 3:   (512-byte records)
	Standalone \fIrestor\fR(1) program
File 4:   (512-byte records)
	Standalone \fIicheck\fR(1) program
File 5:   (512-byte records)
	Standalone \fIadb\fR(1) program
File 6:   (10240-byte records)
	Root filesystem in \fIdump\fR(5) format
File 7:   (10240-byte records)
	'/usr' filesystem in \fIdump\fR(5) format
File 8:   (10240-byte records)
	Source for commands in \fItar\fR(1) format
File 9:   (10240-byte records)
	UNIX documentataion in \fItar\fR(1) format
.DE
.PP
The system as distributed contains binary images
of the UNIX kernel and all the user level programs, along with source
and manual sections for them -- about
2300 files altogether.
The binary images,
along with other
things needed to flesh out the file system enough so UNIX will run,
are to be put on one file system called the `root file system'.
The minimum file system size required is about 6000 blocks.
The second file system has libraries, the online manual, and
source for the UNIX kernel,
occupying another 6000 blocks.
Machine-readable documentation and source for all commands
are supplied in `tar' format, to be extracted as required.
Altogether it amounts to more than 22,000 512-byte blocks.
.SH
Making the Root Filesystem from Tape
.PP
Perform the following bootstrap procedure to obtain
a disk with a root file system on it.
The procedure assumes a console terminal at address x'10',
using the highest baud-rate clock and even parity.
.IP 1.
Mount an empty, formatted disk pack on drive 0
(i.e. the drive with the lowest hardware address).
.IP 2.
Mount the magtape on drive 0 at load point.
.IP 3.
Read \fIboot\fR(8)
(i.e. the entry BOOT in Section 8 of the `UNIX Programmer's Manual'),
and follow the instructions for
loading the `boot' program from tape,
using either the "50 Sequence" (7/32 or 8/32) or the LSU (3220 or 3240).
.IP 4.
The console should type
.DS
.I
Boot
:
.R
.DE
Copy the root file system dump from magtape to disk by the following procedure.
The machine's printouts are shown in italic,
explanatory comments are within ( ).
The input `d67(0,0)' means "67MB disk, drive 0, offset 0 blocks from the
beginning of the pack".
For other configurations, you should substitute:
.DS
dsk(0,0)        ( 10MB disk, removable platter )
dsk(1,0)        ( 10MB disk, fixed platter )
d40(0,0)        ( 40MB disk )
d256(0,0)       ( 256MB disk )
.DE
In the case of "non-standard" hardware addresses
( see Table 2 in \fIboot\fR(8) ),
type `*' in place of the drive number
( e.g. `d67(*,0)' )
and reply to the prompts for device / controller / channel address.
.sp
Terminate each line you type by carriage return.
If you should make a mistake while typing, the character '#'
or backspace
erases the last character typed on the current line,
and the character '@' erases the entire line typed.
Some consoles cannot print lower case letters; adjust the
instructions accordingly.
.DS
(bring in the program mkfs)
\fI: \fRmt(0,2)
\fIfile system size:\fR 9600
\fIfile system:\fR d67(0,0)
.I
isize = XX
m/n = XX
.R
(after a while)
.I
exit called
Boot
:
.R
.DE
This step makes an empty file system.
.IP 6.
The next thing to do is to restore the data
onto the new empty file system. To do this you respond to
the `\fI:\fR' printed in the last step with
.DS
(bring in the program restor)
\fI: \fRmt(0,3)
\fItape?\fR mt(0,6)
\fIdisk?\fR d67(0,0)
\fILast chance before scribbling on disk.\fR (you type return)
(the tape moves, perhaps 5-10 minutes pass)
\fIend of tape\fR
.I
Boot
:
.R
.DE
You now have a UNIX root file system.
.SH
Booting UNIX
.PP
You probably have
the bootstrap running, left over from the last step above;
if not,
repeat the boot process (step 3) again.
Then simply enter
.DS
\fI: \fRd67(0,0)unix
.DE
The machine should type the following:
.DS
.I
Memory = xxx.xx K
#
.R
.DE
The
.I
Memory
.R
message gives the memory available to user programs
in kilobytes.
.PP
UNIX is now running,
and the `UNIX Programmer's manual' applies;
references below of the form X(Y) mean the subsection named
X in section Y of the manual.
The `#' is the prompt from the Shell,
and indicates you are the super-user.
The user name of the super-user is `root'
if you should find yourself in multi-user mode and
need to log in;
the password is also `root'.
.PP
The next thing to do is to restore the '/usr' file system from the tape.
In the instructions below,
comments are enclosed in ( ); don't type these.
The number in the first command is the
size of the file system.
.DS
/etc/mkfs /dev/msm0c 9600       ( or `/dev/dr0' for 10MB removable disk )
tc ff 6                         ( skip 6 files on the tape )
restor r /dev/msm0c             ( restore the file system )
(Reply with a `return' (CR) to the `Last chance' message)
.DE
.PP
You may at this point mount the '/usr'
file system (mount(1)). To do this type the following:
.DS
/etc/mount /dev/msm0c /usr
.DE
The kernel source is now available in '/usr/sys'.
.PP
Before anything further is done the bootstrap
program should be copied to the disk.
This is done using the command
.DS
/etc/mkboot -9600 /boot /dev/msm0
.DE
if you have the MSM drive, or
.DS
/etc/mkboot -9600 /boot /dev/df0
.DE
for 10MB drives.
Now the Perkin-Elmer LSU bootstrap is usable.
See \fIboot\fR(8) for further information.
.PP
Before UNIX is turned up completely,
a few configuration dependent exercises must be
performed.
At this point,
it would be wise to read all of the manuals
(especially `Regenerating System Software')
and to augment this reading with hand to hand
combat.
.SH
Reconfiguration
.PP
The UNIX system running is probably a "standard" system
with the given disk
and tape, a console, and no other device.
This is certainly not the correct
configuration.
You will have to correct the configuration file to reflect
the true state of your machine.
.PP
It is wise at this point to know how to recompile the system.
Print (cat(1))
the file /usr/sys/conf/makefile.
This file is input to the program \fImake\fR(1) which
if invoked with `make all' will recompile all of
the system source and
install it in the correct libraries.
.PP
The program mkconf(1) prepares files that
describe a given configuration (See \fImkconf\fR(1m)).
In the /usr/sys/conf directory,
the file 'config'
was input to mkconf to produce the version of the system in
/unix.
You will need to edit it to describe your own configuration.
Then run mkconf;
it will generate the files param.s (assembly parameters) and
c.c (configuration tables).
Take a careful look at
these files to make sure that all the devices that you
have are included at the right addresses.
.PP
After all the corrections
have been made,
use make(1) to recompile the system (or
recompile individually if you wish: use the makefile
as a guide).
If you compiled individually, say `make unix' in the
directory /usr/sys/conf.
The final object file (unix) should be
moved to the root, and then booted to try it out.
It is best to name it something like /nunix so as not to destroy
the working system until you're sure it does work.
See \fIboot\fR(8) for a discussion
of booting.
Note:  before taking the system down,
always (!!) perform
a sync(1)
to force delayed output to the disk.
.SH
Special Files
.PP
Next you must put in special files for the new devices in
the directory /dev using mknod(1).
Print the configuration file
c.c created above.
This is the major
device switch of each device class (block and character).
There is one line for each device configured in your system
and a null line for place holding for those devices
not configured.
The essential block special files were installed above;
for any new devices,
the major device number is selected by counting the
line number (from zero)
of the device's entry in the block configuration table.
Thus the first entry in the table bdevsw would be
major device zero.
This number is also printed in the table along the right margin.
.PP
The minor device is the drive number,
unit number or partition as described
under each device in section 4 of the manual.
You can also add entries for other disk drives.
.PP
In reality, device names are arbitrary. It is usually
convenient to have a system for deriving names, but it doesn't
have to be the one presented above.
.PP
Some further notes on minor device numbers.
The 10MB disk driver uses the 010 bit of the minor device number to
indicate whether or not to interleave a file system across
more than one physical device. See dsk(4) for more detail.
The magtape driver uses the 0200 bit to indicate whether
or not to rewind the tape when it is closed.
By convention, tape special files with the 0200 bit on have a `m'
prepended to their name, as in /dev/mmt0 or /dev/rmmt1.
Again, see mt(4).
.PP
The naming of character devices is similar to block devices.
Here the names are even more arbitrary except that
devices meant to be used
for teletype access should (to avoid confusion, no other reason) be named
/dev/ttyX, where X is some string (as in `00' or `library').
The files console, mem, kmem, and null are
already correctly configured.
.PP
The disk and magtape drivers provide a `raw' interface
to the device which provides direct transmission
between the user's core and the device and allows
reading or writing large records.
The raw device counts as a character device,
and should have the name of the corresponding
standard block special file with `r' prepended.
Thus the raw magtape
files would be called /dev/rmtX.
These special files should be made.
.PP
When all the special files have been created,
care should be taken to change
the access modes (chmod(1))
on these files to appropriate values (probably 600 or 644).
.SH
Time Conversion
.PP
If your machine is not in the Eastern time zone,
you must edit (ed(1)) the file
/usr/sys/h/param.h
to reflect your local time.
The manifest `TIMEZONE' should be changed
to reflect the time difference between local time and GMT in minutes.
For EST, this is 5*60; for PST it would be 8*60.
Finally, there is a `DSTFLAG'
manifest;
when it is 1 it causes the
time to shift to Daylight Savings automatically
between the last Sundays in April and October
(or other algorithms in 1974 and 1975).
Normally this will not have to be reset.
When the needed changes are done, recompile and load the
system using
make(1)
and install it.
(As a general rule, when a system header file is changed,
the entire system should be recompiled.
As it happens, the only uses of these flags are in
/usr/sys/sys/sys4.c, so if this is all that was changed it
alone needs to be recompiled.)
.PP
You may also want to look at timezone(3)
(/usr/src/libc/gen/timezone.c) to see
if the name of your timezone is in its internal table.
If needed, edit the changes in.
After timezone.c has been edited
it should be compiled and installed in
its library.
(See /usr/src/libc/(mklib and compall))
Then you should
(at your leisure)
recompile and reinstall
all programs that use it (such as date(1)).
.SH
Disk Layout
.PP
If
there are to be more file systems mounted than just the root
and /usr,
use mkfs(1) to create any new file system and
put its mounting in the file /etc/rc (see init(8) and mount(1)).
(You might look at /etc/rc anyway to
see what has been provided for you.)
.PP
There are two 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.
Swap space is a critical parameter.
The system
as distributed has 9500 (MSM disk) or 1600 (10MB disk) blocks
for swap space.
This should be large enough so running out of swap space never
occurs.
You may want to change these if local wisdom indicates otherwise.
.PP
The system as distributed has all of the binaries in /bin.
Most of
them should be moved to /usr/bin, leaving only the ones required for
system maintenance (such as icheck, dcheck, cc, ed, restor, etc.) and the most
heavily used in /bin.
This will speed things up a bit if you have only one disk, and also free
up space on the root file system for temporary files. (See below).
.PP
Many common system programs (C, 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 leave the root file system as distributed
(except as discussed above) there
should be no problem.
All the programs that create files in /tmp take
care to delete them, but most are not immune to
events like being hung up upon, and can leave dregs.
The directory should be examined every so often and the old
files deleted.
.PP
Exhaustion of user-file space is certain to occur
now and then;
the only mechanisms for controlling this phenomenon
are occasional use of du(1), df(1), quot(1), threatening
messages of the day, and personal letters.
.PP
The efficiency with which UNIX is able to use the CPU
is largely dictated by the configuration of disk controllers.
For general time-sharing applications,
the best strategy is to try to split user files,
the root directory (including the /tmp directory)
and the swap area among three controllers.
.PP
Once you have decided how to make best use
of your hardware, the question is how to initialize it.
If you have the equipment,
the best way to move a file system
is to dump it (dump(1)) to magtape,
use mkfs(1) to create the new file system,
and restore (restor(1)) 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 which can be allocated.
For relatively small increases, this word can be patched
using the debugger (adb(1))
and the free list reconstructed using icheck(1).
The size should not be increased very greatly
by this technique, however,
since although the allocatable space will increase
the maximum number of files will not (that is, the i-list
size can't be changed).
Read and understand the description given in file system(5)
before playing around in this way.
You may want to
see section msm(4) for some suggestions
on how to lay out the information on MSM disks.
.PP
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 filesystem.
However, this might not work if the i-list on the smaller filesystem
is smaller than the maximum allocated inode on the larger.
If this is the case, reconstruct the filesystem from scratch
on another filesystem (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:
.IP 1.
GET A SECOND PACK!!!!
.IP 2.
Dump the current root filesystem (or the reconstructed one) using dump(1).
.IP 3.
Bring the system down and mount the new pack.
.IP 4.
Retrieve the UNIX distribution tape and perform steps 1 through
5 at the beginning of this document,
substituting the desired file system size instead of 9600
when asked for `file system size'.
.IP 5.
Perform step 6 above up to the point where the `tape'
question is asked. At this point mount the tape
you made just a few minutes ago. Continue with step 6 above substituting
substituting `mt(0,0)' for `mt(0,6)'.
.SH
New Users
.PP
Install new users by editing the password file
/etc/passwd (passwd(5)).
This procedure should be done once multi-user mode is entered
(see init(8)).
You'll have to make a current directory for each new user
and change its owner to the
newly installed name.
Login as each user to make sure the password
file is correctly edited.
For example:
.DS
ed /etc/passwd
$a
joe::10:1::/usr/joe:
.li
.
w
q
mkdir /usr/joe
chown joe /usr/joe
login joe
ls \-la
login root
.DE
This will make a new login entry for joe,
who should be encouraged to use passwd(1)
to give himself a password.
His default current directory is
/usr/joe
which has been created.
The delivered password file
has the user
.I
bin
.R
in it to be used as a prototype.
.SH
Multiple Users
.PP
If UNIX is to support simultaneous
access from more than just the console terminal,
the file /etc/ttys (ttys(5)) has to be edited.
To add a new terminal be sure the device is configured
and the special file exists, then set
the first character of the appropriate line of /etc/ttys to 1
(or add a new line).
Note that init.c will have to be recompiled if there are to be
more than 100 terminals.
Also note that if the special file is inaccessible when init tries to create a process
for it, the system will thrash trying and retrying to open it.
.SH
File System Health
.PP
Periodically (say every day or so) and always after a crash,
you should check all the file systems for consistency
(icheck, dcheck(1)).
It is quite important to execute sync (8)
before rebooting or taking the machine down.
This is done automatically every 30 seconds by the update
program (8) when a multiple-user system is running,
but you should do it anyway to make sure.
.PP
Dumping of the file system should be done regularly,
since once the system is going it is very easy to
become complacent.
Complete and incremental dumps are easily done with
dump(1).
Dumping of files by name is best done by
tar(1) but the number of files is somewhat limited.
Finally if there are enough drives entire
disks can be copied using cp(1), or preferably with
dd(1) using the raw special files and an appropriate
block size.
.SH
Odds and Ends
.PP
The programs
dump,
icheck, quot, dcheck, ncheck, and df
(source in /usr/source/cmd)
should be changed to
reflect your default mounted file system devices.
Print the first few lines of these
programs and the changes will be obvious.
Tar should be changed to reflect your desired
default tape drive.
