various boot-related questions.

[Jean-Francois Lamy]

People on the phone on the hotline are giving me blank stares :-) when
asked the following:

a) on an SGI 4D/240 using a tty as a console, how does one forcibly enter
   the PROM monitor? (this is often accomplished by BREAK on ttys).  While we
   understand this may not be desirable by default, there oughta be a way
   to make the machine pay attention without having to depress its belly
   button...

b) How does one do the equivalent of a "savecore" upon reboot (the goal is to
   be able to save memory state and peek around to see where things hang).

   Since someone will ask why on earth we'd want to do that - we
   have a machine that runs for several days and all of the sudden refuses
   to fork off new commands (i.e. after typing a command to the shell, all
   you can do is interrupt it; you can connect to the telnet daemon but
   won't get a shell; ping replies do get answered, etc.).  There is plenty
   of memory and plenty of swap space and plenty of process slots.

And while I'm at it, the whole fsck picture makes me and a bunch more people
shudder.

c) What exactly are the "minor repairs" where fsck -b will seek to reboot?
d) What exactly is checked by fsstat? Is the dirty bit just that, a bit, that
   could, say happen to be in a bad block and be wrong?  Is fsck under efs
   guaranteed to clean the filesystem in one pass, or does it suffer from
   the berkeley heritage and therefore sometimes two or three fscks of the
   same partition are required before fsck succeeds twice in a row?
   Why did a message arrive in my mailbox this very second suggesting we
   comment out all the calls to fsstat in the boot sequence and get rid of
   the -c flags in mountall?
e) Can we get a -p flag on fsck (i.e. repair minor damage, report error
   on major damage, causing machine to stay in single user mode).  Using
   -y in the boot sequence sounds like a bit trusting.

Brrrrrr.

Jean-Francois Lamy               lamy at ai.utoronto.ca, uunet!ai.utoronto.ca!lamy
AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4