Eskinews - Booted Linux 2.2.1

[Robert Dinse <nanook@eskimo.com>]

     Linux 2.2.1 successfully booted on Eskinews tonight.  To be sure there are
a few glitches, but the machine seems to be basically operational and
processing news and UUCP traffic. 

     This machine is capable of being a 4-CPU machine and we have four CPUs for
it but we have been running with only 2 CPUs installed because Linux didn't
work properly with a second dual-CPU module on this archetecture prior to this
release. 

     We do not know for sure that it will actually work properly on this
release but if it runs stably for a bit on 2 CPU's I am going to install the
second dual-CPU module and try it with four.  This thing does get CPU saturated
at times and could really use it. 

     Glitches I am seeing thus far include:

	When it boots, it does about eight modprobe's that fail, we don't have
	loadable modules compiled in so I don't know why it is trying to do
	this.  I don't see anything obviously break because of this, just an
	annoyance as far as I can tell. 

	When it goes to mount file systems from remote machines, it attempts
	to access portmapper.  Only problem is portmapper isn't started at that
	point.  So all the mounts timeout, then it starts portmapper, then it
	successfully mounts the file systems.  Problem is this breaks some
	things that get started before the mount succeeds.  This will require
	some twiddling of the RC scripts but should be correctable. 

	The rstatd daemon doesn't function properly with respect to packet
	counts, disk I/O, or collisions coming up with absurdly high numbers
	for all of these things that do seem to track traffic.  I assume some
	changes have been made to /procfs, such as the sample intervals, and
	an updated rstatd will probably take care of this particular issue.
	At any rate, not a show-stopper. 

	I don't know what is necessary to utilize the kernel NFS, but I don't
	believe we are now.  The nfs daemon is still running, still
	accumulating CPU.  I assume this will require some configuration
	changes to utilize but I don't know enough about it to know exactly
	what is required - yet. 

     Inn appears to be running a little faster and smoother under this kernel
but it hasn't been up long enough to see how it response to busier hours when
it is hammered with more requests. 

     The good news is it successfully booted, the 2.1.x kernels did not
successfully boot on this machine and even 2.0.x kernels newer than 2.0.33 were
not stable on it.