From: mbeattie@black.ox.ac.uk (Malcolm Beattie) Subject: Another Linux start-up saga Date: 20 Oct 1992 15:16:22 GMT
After reading here about Linux for many months, salivating
all the time, my ordered PC arrived a few weeks ago and I
started installing Linux. Here are a few notes and problems
on that long road to a complete installation:
Configuration: 486/33, AMI BIOS
16 MB memory
240 MB Quantum IDE hard disk
1 3.5inch diskette
ET4000 SVGA card (1 MB)
Serial mouse
OS versions: 0.98 + one-line hd.c patch
gcc `2.2.2d7' distribution with jump 4.1
X 2.0
I installed initially with the MCC 0.97p2 distribution,
and the basic installation was fine (I'd already practised
with a base 0.97 boot+root on a 386.) I ftp'ed the stuff to
a SUN SPARC2 and then (fdformat'ed and) dd'ed to diskette---no
problems there. The first problem occurred after using a
DECstation 5000/25 to dd the 0.98, 2.2.2d7, jump4.1 and X2.0
stuff onto diskettes I got home for the weekend and prepared to
install...
Some of the diskettes had been formatted (fddisk -fmt) and
then tar'ed from the DECstation; some of the others I just
tar'ed stuff onto diskettes previously formatted by the SUN.
On tar'ing from these latter diskettes, my diskette drive would
begin making truly awful noises and whole strings of
`floppy errors' and `floppy reset' errors would appear. Once,
Ctrl/C wouldn't even interrupt this and I had to reset.
I am told that some machines drives are right at the edge of
their tolerances---it would seem that two out of the three
machines SUN, DECstation, PC must have been right at opposite
edges. After reformatting the errant diskettes on the DECstation
and writing back the data from the same, there was no trouble
with the diskettes.
It is worth keeping this in mind, perhaps, for those that have
access to a number of different workstations.
Time passed...
The installation of `gcc 2.2.2d7' and the jump libraries (4.1)
went (relatively) cleanly; the installation of X less so.
There are (were?) a number of important configuration files
that lie in directories which are only obvious in hindsight.
Unfortunately, hindsight is such that I can't even remember
which caused the most trouble. (/usr/X386/lib/X11/xinit/Xconfig
or something?) The paths may have changed again in XFree... though.
I now have X, TeX, MF etc. up and running marvellously.
Now, however, for the details of the one time that I
have managed to lock Linux up competely:
Ingredients: One xterm, one large (~11 MB) database.
The database is a list words and related info (pronunciation,
frequency etc.)---each line with one (upper case)
word starting at col 57 followed by '|', followed by other fields.
To extract a list of words from
it, I put together a fairly long pipeline of the rough form
tail +300 largefile | cut -c57- | sed 's/|.*//' | \
tr -cd [\nA-Z] | tr A-Z a-z > listout
I can't remember the exact command but piping to more instead
of redirecting to listout did the expected thing.
I set it going and after 5 or 10 seconds of ordinary hard disk
activity, the hard disk activity increased markedly (swapping
onto the 16 MB swap partition, I would guess.) After another
5 or 10 seconds or so the disk activity stopped and there was
no response from the keyboard at all. I think I heard/saw a sync
happen some seconds afterwards. I left it for quite a long time,
and returned to find it still locked up. No more syncs were
happening (the hard disk LED normally flickers for a sync, even
with nothing needing writing.)
The keyboard was still locked up: None of the following had any
effect: Ctrl/C, Ctrl/Z, Ctrl-Alt-Del, Ctrl-Alt-Backspace (this was
under X, remember). I did a hard reset and fsck didn't indicate
any damage-the output file (listout, above) had got about half way
through the file. Testing indicates that sed is the problem:
Doing only the sed step (not under X) and hitting
whatever+Scroll Lock shows all the figures diving towards zero.
Perhaps sed has a memory leak?
As soon as patch1 for 0.98 came out, I tried to install that
but the patch failed on msbusmouse.c so I just applied the
one-line hd.c patch by hand. (It had already mentioned as a
stand-alone patch and the rest of patch1 involved SCSI, which
I haven't got, and mouse detection, which is O.K. for me anyway.)
I have since seen someone mention that patch can have problems
creating files---maybe that was the problem.
Finally, the obligatory praise. Linux really is excellent and
I have already managed to persuade quite a number of people
to consider using it. Thanks to Linus and everyone else for
making it that way.
I intend to become an active Linux user/helper, although I will
be rather busy over the next couple of months.
--Malcolm
-- Malcolm Beattie <mbeattie@black.ox.ac.uk> | I'm not a kernel hacker Oxford University Computing Services | I'm a kernel hacker's mate 13 Banbury Road, Oxford, OX2 6NN (U.K.) | And I'm only hacking kernels Tel: +44 865 273232 Fax: +44 865 273275 | 'Cos the kernel hacker's late