Endless bummer...

John B. Milton jbm at uncle.UUCP
Mon Aug 7 12:40:07 AEST 1989


In article <1582 at mtunb.ATT.COM> jcm at mtunb.UUCP (John McMillan) writes:
>In article <802 at bagend.UUCP> jan at bagend.UUCP (Jan Isley) writes:
>>In article <9832 at csli.Stanford.EDU> crimmins at csli.stanford.edu (Mark Crimmins) writes:
>>>This has happened to me a couple of times, and I wonder if anyone
>>>knows why.  I turn on my 3b1 (3.5M 67HD rev. 3.5 sys and utils) and it
>>>goes through the normal boot procedure until the "checking stored
>>>files" screen turns to gibberish and then the boot procedure starts
>		^^^^^^^^^^^^^^^^^^
>>>over (and over and over).  The problem goes away when I "upgrade" all
>>>system files from floppy, including utilities.
>:
Hmm. Turn to gibberish. I would read that to mean the binary count pattern
the boot ROM puts up when it test video RAM.

I modified my /etc/rc a long time ago. Yeah yeah. Well, lets take a closer look.
Let's look at the relevant code without the bogus comments.

/etc/fsck -pq > /dev/null || (
  if [ -r /etc/.installdate ]; then
    date > /etc/.lastfsck
    /etc/fsck -y >> /etc/.lastfsck
  else
    /bin/sh
  fi
)

The -p for preen switch seems to be unique to the UNIXpc. The man page for fsck
specifically mentions this feature should be used in /etc/rc for un-attended
booting. Booting does not always happen when the stupid comments say it will.
When the "fsck -pq" finds and fixes minor problems it WILL reboot the system.
The vast majority of all file system problems are minor. When minor fixes are
complete and the system reboots, the || part obviously never gets run. If the
"fsck -pw" finds something real nasty, it exits with a bad status and the ||
part does get executed. If you are just now installing the system, the file
.installdate will not exist, and it will just dump you at a shell prompt with
scary error messages. If your system has been installed, the redirection to
/etc/.lastfsck is done with an "fsck -y". I do very much agree that this is
very stupid. The correct way to do this would have been to overwrite a pre-
existing, pre-allocated file, much the same way /lost+found is used, using a
special switch to fsck, say -L. If too much is written, output just stops.
The way it is with the installed /etc/rc through, when things are really
bad, /etc/rc makes it worse. Hmm. maybe bad enough for a, ah, service call?

John
-- 
John Bly Milton IV, jbm at uncle.UUCP, n8emr!uncle!jbm at osu-cis.cis.ohio-state.edu
(614) h:294-4823, w:785-1110; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!



More information about the Unix-pc.general mailing list