On Thu, Jan 18, 2001 at 09:48:40PM -0700, Ronald G Minnich wrote:
> The overall question: how do we balance a desire to get optimal settings
> with the desire to actually boot even if we make the wrong settings, so we
> can fix things from over the network.
>
> The way you get to "best" settings now is to get into CMOS via the BIOS
> "hit <DEL>" approach and interactively set things. Even now, in CMOS
> settings, you can set things in such a way that the machine won't boot.
> Your only option is to physically open the machine up and reset CMOS.
> BIOS writers assume you've got a keyboard, monitor, and screwdriver. This
> will not work in the cluster world.
Can you provide a realistic case as to why an entire cluster would have
been loaded with a linuxbios with settings that fail to boot the machine?
I still fail to see why you couldn't require the console to force "safe"
settings if you get too agressive. Are you really testing new settings on
your whole cluster simultaneously?
Basically, it seems to me you're modifying the basic architecture of
linuxbios for cluster applications. This change is rather unfriendly
towards embedded systems or thin-client type systems. Isn't that a *bad*
thing?
Another idea: linuxbios, as it starts, stores a magic value somewhere
(say, in CMOS ram) that basically says "I'm booting with agressive
settings". Then, when linux hits runlevel 3, you have a userspace app go
and erase that magic value.
Then, if a system ever fails to boot with agressive settings, you could
simply power-cycle (or reset the box in any way) and when linuxbios boots
it can see that the magic value is already present, and knows the previous
boot must have failed... therefore it uses the safe settings.
Eric
