Eric W. Biederman wrote:
>>> How about recovery via a checksum so that if the systems fails to load
>>> the kernel it jumps to from LinuxBIOS you can recover via the keyboard
>>> with some key combination so that you can choose another boot option
>>> and/or at least see why it failed?
>>
>
> If you detect failure recovery is straight forward. Detection of
> failure is the tricky part.
If you detect a failure via a checksum the LinuxBIOS could jump to a
secondary location for a working kernel.
> If you jump to a loaded kernel linuxBIOS is gone. Poof. There is no
> recovery short of rebooting. Rebooting is the only way to get back into
> linuxBIOS.
That's where a watchdog would come in handy but there are no standards
for a watchdogs. A watchdog could be used if we include in LinuxBIOS a
way to record the last good jump to a kernel. If the record is good try
the primary kernel location for boot. If the record is bad jump to a
secondary kernel location. This would all rely on being able to write to
the Flash holding the LinuxBIOS after a good load of a kernel and be
cleared after LinuxBIOS has checked it.
>
>> This would not be handy for clusters
>> but would be nice for embedded apps like SBCs, webpads and
>> set-top-boxes.
>
> I don't see how a key combination would be useful. Either you
> are in linuxBIOS and you have control. Or you are not in linuxBIOS and
> you can't do anything.
Using a key combination could bring up a screen that could be used to
have a choice of where to jump to if the checksum is bad or without a
screen to give a user choice of a secondary kernel location.
example:
checksum is bad on main kernel location = some output... pc beep, video
out, packet out to Lan, etc.
key combination
ctrl + 2 = secondary hard drive
ctrl + 3 = CDROM
or you could have directions in LinuxBIOS to jump to a secondary kernel
if the primary kernel checksum comes back bad.
Bari
