Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!amdahl!pacbell!sactoh0!tree!stever
From: stever@tree.UUCP (Steve Rudek)
Newsgroups: comp.unix.microport
Subject: ps INSISTS on accessing the floppy (/dev/rdsk/fd) on SysV/AT 2.4
Keywords: ps
Message-ID: <264@tree.UUCP>
Date: 9 Apr 89 01:24:32 GMT
Organization: TREE BBS (916)-349-0385 Sacramento, Ca
Lines: 27

About 2 months ago a double panic made the root file system (/dev/dsk/0s0)
unbootable.  In previous instances of file system corruption I'd escaped
similar problems by running Microport's installit program specifying the
"upgrade" path rather than a new installation (which would mkfs all the file
systems and wipe out important stuff on /dev/dsk/0s2, etc).  In this case,
though, the disk remained unbootable -- clearly the problem was at a lower
level.

Looking at the installit script revealed that when doing a new installation
the script referenced a "list" file to determine which files to copy across
while a shorter "list.ug" file was used when following the upgrade path.  So
I hatched the idea of hacking a backup copy of the boot floppy disk to
"cp list list.ug" before doing an 'upgrade'.  Voila!  The root file system
once again became bootable and I figured that was the end of THAT.

It wasn't -- not quite. There was one side effect to my hack that I can't
figure out.  Everytime a ps is run, the system INSISTS on accessing the
floppy drive.  It doesn't DO anything on the drive but it insists on having
a floppy in there and turning on that cute little red light before it will
agree to do anything else.

It's not the worst problem in the world -- heck, I've managed to put up with
it for nearly 2 months now.  But it is irritating and I would like to get to
the bottom of it. I figure that there must be a modified file or something
somewhere.  Or perhaps there's something different about the kernel?

I don't know.  Does anyone?