From: Philip Blundell <pjb27@cam.ac.uk>
> Bizarrely, precisely the same thing happened to me last week. I had just
> upgraded to 2.0.20 (from 2.0.4) and was doing a fresh install on one
> machine off CD-ROM. When it came to reboot with the newly-installed
> system, gzip was corrupt in some way (though the file length was right).
> I never worked out how it happened. I reinstalled again and the problem
> didn't recur, though it was a bit worrying.
>
> It seems a bit improbable that it's a kernel thing though. At the time I
> put it down to cosmic rays or something, because I didn't have time to
> chase it properly.
I have not had much time to work with the 2.0.20 kernel, but since it was
new I have been at the 2.0.10 kernel and had a "similar" problem. I say
"similar" since it is a "weird" corruption like the above two, but it
affected the system in a different way... I believe the cause of the
problem might be from a program I trying to get running ( an OpenLook
Windows Manager that came from a year old Slackware CD).
I was logged in as root (a big no-no) and changed roots' default window
manager in .xsession and started up XWindows. Unfortunately, with my X
server (Accelerated X from X Inside Inc. running on Caldera Ver 1.0) when I
go back to Text mode the screen is in power-saving mode and I can't get the
text back. Because of this, I could not see why X was dying. When I
rebooted and tried to login as root, I would login but then the Virtual
Console would hang. I switched to another VC and could login as my dlinder
user with no problem, but doing a "su" to root hung also. I rebooted into
single user mode and made a suid-root shell, booted normally and the
suid-root shell worked fine. I got to looking around and found that nearly
EVERY file on the system had the group-id set to the bogus "httpd" user
group (GID 501). I did a find/chgrp and fixed things up to where they
seemed normal and attempted the XWindows again. Again, it died and I had
to go through the same things.
I upgraded to 2.0.20 but have not tried this same test on that kernel or
other user IDs... Does anyone remember if there is a "bad" program
floating around that might do this, or a reason that an otherwise well
behaved program could go bad? If I turn up more problems or a solution I
will write more later.
Dan
--- Daniel Linder -- WebCentric Communications (402) 346-9466 http://www.webcentric.net