On Mon, Jun 19, 2000 at 09:55:30PM -0400, Greg A. Woods wrote:

 > That's because it uses completely upside-down and inside-out logic.  The
 > correct test is not to see if there's a serial port connected (quite the
 > contrary since there might not actually be anything connected at boot
 > time, or if it is it might not be powered up or whatever), but rather to
 > test if a PC keyboard is connected.  For the most part it seems almost
 > all Suns have been using the lack of a keyboard to default back to the
 > serial console (even if the EEPROM says to use the keyboard) and there
 > have been far fewer problems with this scheme.

Of course, Sun's aren't PCs, and thus don't suffer from the wide
range of lossage that crappy PC hardware can cause... such as "keyboard
is really connected, but still fails the `reset' command".

 > > The existance of different biosboot* versions is kind of a workaround
 > > for the lack of non-volatile storage on PCs.
 > 
 > Is this still true on modern, particularly server-class, machines?

Yes, it is.  I've been having to deal with this ... quite
up-close-and-personal for the last couple of months.  PCs suck, I just
wish I could be using Alphas for my particular application.

 > 
 > On the other hand it shouldn't be too hard to use disk storage for this
 > purpose.  Doesn't almost every install reserve as many as 64 sectors
 > before the start of the first partition, only one of which is used for
 > the MBR?  I realize this isn't a hard enforced convention, but it
 > shouldn't be too hard to reserve a single bit flag in the master boot
 > program to make this determination at runtime.....

A better idea would be to have the values in /boot itself, which /boot
could subsequently modify by writing the correct block back to disk.
That way, installboot could easily frob the values, too.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>