hall@cod.NOSC.MIL (Robert R. Hall) (07/21/89)
Bringing Up Minix 1.3
=====================
ABSTRACT
This paper is a summary of the experiences of a naive user in bringing up
Minix. It focusses on building the IBM PC version 1.3 of Minix from the
Prentice Hall 1.3 update sources, using Minix as the development system.
Various problems are outlined, together with the solutions found. The paper
will not be of interest to experienced users, but may be useful to those
starting out with Minix.
BACKGROUND
I have a long-standing amateur interest in computer languages, and was
interested in the Unix system's language-development tools, although I had
never used Unix. When Minix came out the price was within my reach and I
ordered a copy; fortunately my order was delayed so that I got 1.2 not 1.1, in
early 1988. RAM prices and other problems then put the cost of a PC clone out
of reach until early 1989, and I ran Minix intermittently on the twin-floppy
PCs of a local university. The incessant disk-swapping was discouraging, as
was the lack of a printer. In early 1989 I bought an IBM clone with a 10MHz
DTK motherboard and ERSO bios, 5.25 and 3.5 floppies, a 40 MB 40 mS Seagate
ST-251 hard drive with a Western Digital 'auto-config' controller, and two RS-
232 ports. These specifications were set with Minix in mind. To run various
application programs I bought MSDOS 3.3.
The first problem was to partition the drive between the two OS. MSDOS
would not recognise Minix partitions, and would produce only two partitions
instead of the three I wanted. Minix would not add partitions to MSDOS,
complaining of overlap, and MSDOS would not read from a disk partitioned ab
initio by Minix. After three low level formats in two days I gave up and
accepted MSDOS' two partitions; 20M for MSDOS on hd1 and 18M for Minix on hd2,
with 2M left for later allocation. I then found that Minix would not make a
larger file-system than 510K on the second partition. The answers to these
problems are discussed below, but at the time I did not feel capable of
debugging and rebuilding Minix on what was effectively a single-floppy system.
The solution underscored the importance of Usenet for Minix users; I had
got read-only access via a local BBS, and noticed that a student attending the
same University (on the next floor down!) was developing Minix extensively. I
asked her for help, and was given a copy of Minix with the AUTO_BIOS known to
be set true; it then became clear that the Prentice-Hall 1.2 binary did not
follow the 1.2 source in this respect. The new version gave me an 18M file-
system on hd2, and I could start building 1.3 from the Prentice-Hall update.
MINIX 1.3
3.5" Floppy Driver
Fdisk (and fsck) still didn't work, so I added hd3 to the partition table
by reading the disk with dd, patching the file under DOS with debug, and
writing the file back with dd again. The speed gained from loading the RAM
disk from the hard drive proved its worth when debugging the 1.4 floppy driver
for the 3.5 drive. This was straightforward - the flag pc_at needs to be set
true to enable DMA speed changing. Since pc_at is used elsewhere in the code
I simply removed the related 'if' statements from the floppy driver.
The work on this driver (a trivial task to the knowledgeable) showed me
that I had been right to think a hard disk essential. When solutions must be
reached by some measure of trial and error, it is important to have a simple
process with fast turn-around. The makefiles of the Minix distribution are
ideal for inexperienced users; it took two commands and about 10 minutes to
rebuild the system with each change to the floppy driver. However, all the
files must be available in the places in which the system expects to find
them. This needs a hard disk of at least 10M capacity; after building my 1.3
system and adding 1M or so of utilities and patches, df reports 7.9 MB used.
Commands
I then started recompiling all the commands, and ran into several
problems. The first was a system administration problem caused by my lack of
knowledge of the Unix filesystem naming conventions. Manuals give an outline,
but little detail of exactly what directories should be found under eg.
/usr/include. (The only book I could find on administration, Fiedler & Hunter
(1986), didn't cover the /usr/include problem). After various experiments I
decided that some files must actually be missing, and hunted through past
Usenet messages. For the second time Usenet proved essential to the
enterprise; the files had in fact been posted, and I downloaded them from the
Mars Hotel BBS (301-470-3569). The files needed are sys/dir.h, sys/timeb.h,
sys/times.h, (not time.h, which is in include), and types.h. The blocksize.h
file also needed to be moved, from include to include/minix. Paragraph 25 of
the 1.3 USER_GUIDE should therefore not be taken as a complete summary of the
include/sys, include/minix and include/fs directories.
With the above additions to these directories all the commands compiled
without error with the exception of sed, cpdir, and cc. CMASK is defined in
stdio.h and was therefore commented out of sed, cpdir needed a tag added to
the structure on line 31 (why I don't know), and cc needs to have a machine
type defined. Compress and tr produced three and one 'pointer warnings'
respectively, and the new compress didn't in fact work, but there are two
binaries on the update disks; the new tr seemed ok. Animals, grep, gres, tset
and tty had unresolved references, which were cured by the rebuilding of
libc.a discussed below. After this was done, compile time for all commands
under a batch file and with 60K space on /tmp was 2.5 hours; ed, roff, and sed
still ran out of space and were compiled by hand.
Some commands were missing altogther. Inspection of the 1.2 binaries
showed that the missing 'true' was simply a zero-length file, but 'spell',
'which', 'write' and 'whereis' were not in 1.2 or in the 1.3 update, although
mentioned in the 1.3 man_pages. Most of these commands are probably shell
scripts. The file help.dat mentioned in the elle installation document was
also absent, and the elle documentation terse to the point of inadequacy.
Libc.a
The next task was to produce a new version of libc.a. The sources
supplied compiled cleanly, but did not represent the whole contents of the old
library. Some functions are supplied only in compressed form in libc.a, and
must be extracted and installed in any new library. The problem then became
one of ordering the new library, and after a lot of tinkering I found an
algorithm to do this. Several methods have been published on Usenet in the
past, and ast has published the order of his own library, but I wanted a
method that would order any future library I might make. To achieve this I
had to abandon my plan to use only the 'official' 1.3 (and the 1.4 floppy
driver), and add Monty Walls' March 1989 changes to lorder, tsort and ar.
Among other things, these allow ar to handle the long argument list for libc.a
via a 'response file', an essential feature.
Since I couldn't make anyone else's method work, here is the algorithm I
used for producing an ordered libc.a:
1. Compare a list of the source files, including those that are machine-
specific, with the contents of the current libc.a and extract from the old
library all those files whose source is not already held externally.
2. Compile any uncompiled files, and pack any unpacked assembler files, such
as those in IBM_PC.
3. Put all the files intended for the new library into a single (unordered)
library. This stops lorder failing with excessive input. Feed lorder the
unordered library, and it will produce output of the form:
a.s b.s
c.s b.s
d.s b.s
.
.
a.s f.s
b.s f.s
c.s b.s
.
.
y.s y.s
x.s x.s
z.s z.s
etc.
4. Edit lorder's output file as follows:
Remove all duplicates of the form z.s z.s above. (I used bawk, but an
editor and patience would do it). Then remove the second instance of all
repeated lines, of the form c.s b.s above; there are twenty eight of these.
(I used mined, but sed and patience would do it). Finally, remove the line
'catchsig.s signal.s'. At the end, tsort should accept the resulting file
with absolutely no comment; the output from tsort can then be fed to ar to
produce a correctly ordered libc.a.
Why this works is a mystery to me, but the resulting library was used to
rebuild all the commands without any unresolved references.
It is not clear whether the file end.s should be part of libc.a or not;
the tools directory makefile certainly looks for it as a separate file in
/usr/lib when building init.
System Changes
Recompiling the kernel to include the two RS-232 ports was straight-
forward, and I was able to edit ttys to 100/0f1/0f2 and log-in at 9600 baud
with no difficulty. Term also ran smoothly first time.
I was able to find a Real-Time-Clock reading program in the Mars Hotel
archives which worked with my clock-card's fairly standard MM58167 chip. An
RTC is an essential with Minix, to keep 'make' working properly.
The problems mentioned at the start with fsck and fdisk were found to be
due to the hard-coding of the number of heads on the hard-disk; both programs
also had the sectors per track hard-coded to 17, which would need to be
changed for an RLL drive. Once the heads parameter was set correctly both
programs worked well, and fdisk was used to add a fourth partition to the hard
drive. This is the sort of snag that is trivial in retrospect (it took 20
minutes or so to fix once I had gained the experience to understand it) but
which is a major problem to those starting out. Fsck was recompiled both as a
program running under Minix, and with a -D option that removed the menu of the
startup version. The hardware now boots MSDOS by default, or Minix if the
boot disk is in drive A, with the process continuing without intervention to
the login: prompt. The backup disk boots to the fsck menu.
The problem with the 510K filesystem on hd2 was due to the hard disk
driver being coded for a default 306 cylinders, 4 heads and 17 sectors. Minix
thus saw the end of the disk (the maximum sector number) shortly after the end
of the first 20MB partition.
The on-line help is extremely welcome to beginners, but the 1.3 version
is only an update and the 1.4 (full) version was badly garbled somewhere.
Concatenating these two versions with 'The Book' took a long time - I then
checked the result against the 1.3 command sources, and found a number of
update options had not been caught. A tedious job, but well worth it.
Terrence Holm's disk editor is a very useful-looking program, which
compiled with only one pointer warning, and should enable device files to be
patched with sizes. Another program useful to the beginner is the man
command, from Banaham & Rutter (1982). This is a shell script that looks like
the Unix 'man', and is ideal for locally generated indices to eg. commands and
directories. My final recommendation is Peter Housel's SVC system, which
compiled without any problems and should make the update to 1.4, which I
intend to tackle next, a lot easier.
CONCLUSIONS
Minix 1.3 is a solid operating system with a full range of capabilities,
that can be used for its own development. It is adequately fast on a 10MHz
IBM XT with one user. For the most effective use of the system, eg. for
access to its on-line help, a hard disk is necessary. To recompile the
system, which given its teaching role is not an uncommon requirement, a hard
disk of at least 10MB is required. An experienced user can work with much
less capable hardware.
For those starting to use Minix outside a formally-taught course access
to Usenet or an experienced user is essential.
AFTERWORD
I've learned a great deal and had enormous fun with Minix, and expect to
continue to do so. My thanks to all those on Usenet who wittingly or
unwittingly made it possible (starting with ast). I can't post to the net as
a rule (this is being posted by a friend), so please don't reply.
Good luck.
C W Rose
San Diego
18 July 89
BIBLIOGRAPHY
Banaham, M. F. and Rutter, A. (1982). UNIX - The Book. Wilmslow, Cheshire,
UK: Sigma Technical Press.
Fiedler, D. and Hunter, B. (1986). UNIX System Administration. Indianapolis:
Howard Sams & Company.
Kernighan, B. W. and Pike, R. (1984). The UNIX programming environment. New
Jersey: Prentice Hall.
McGilton, H. and Morgan, R. (1983). Introducing the UNIX system. New York:
McGraw-Hill.
Tare, R. S. (1987). UNIX utilities. New York: McGraw-Hill.
The above titles (in addition to Dr. Tanenbaum's opus) are those I've
found useful in understanding Minix. McGilton and Morgan's book is especially
valuable, in that it deals explicitly with Version 7, in more depth than
Banaham and Rutter. For the new user, who has to be user, super-user, and
system administrator all in one and immediately, Fiedler and Hunter's book is
well worth reading.