DragonFly kernel List (threaded) for 2009-03
Re: DragonFly boot2 - moved out of commits thread
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Trace: 1236233371 crater_reader.dragonflybsd.org 880 188.8.131.52
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:13524
Justin C. Sherrill wrote:
> On Wed, March 4, 2009 6:46 pm, Bill Hacker wrote:
>> Meanwhile - perhaps you could pick up the DragonFlyBSD logo off the site
>> and see about getting it slimmed-down to a 4-bit .pcx that works?
>> Or perhaps its creator could do so, given the .pcx parameters?
> To make this a bit easier on whomever volunteers, I added .eps and .ai
> versions of the official logo to the images page:
I'll leave the graphics to others and focus on puling up more menu
options from the underlying Forth structure.
As said - it may be a month or so before I can actually DO anything
though - having to make an unplanned three-week HKG-US-HKG excursion.
I'd also like to explore a friendlier 'nextboot' option, one that would
have to live in a later fully-operational stage.
Rationale, and two environments where it could be handy:
A) remote server, where one has limited or no 'local hands'
-- has fallen-back to a 'maintenance' boot system, perhaps network-loaded.
-- repairs or updates completed from that, a reboot to some OTHER mount
wanted, but no console in reach. One can do this now, by re-riting the
boot blocks, but foot-shooting is easy, unless it is done often. Even
B) R&D box where one IS 'at the console' but simply wants the
convenience of being able to jump between, for example different rev
levels if not different race of OS while sorting <whatever>, AND nOT
having to 'hover' so as not to miss the opportunity to make the
selection....then pick the wrong one anyway...
. .. either as a precursor to 'reboot' or an immediate invocation of it.
OS/2 had this inherent, BTW. 'boot -<whatever>'
What it did NOT have was a fallback after timeout to the current,
presumed 'known good' mount. One that *at least* comes up ready to
listen to the mothership on ssh so you can try again...
Parts of this exist. All of it, really. Somewhere.
But could certainly be made more intuitive and easier to use w/o harm.
'Conventional wisdom' is that once dispatched, there is no recall
(absent hardware 'watchdogs' - which I happen to have a few of).
However - there should be a way to remain in some form of 'overseer'
mode - think DOM0 and paravirtualization - that is not shed until a
successful phase of the boot come on-deck and kicks it out...
JM2CW, but long-term, it could be cheaper than an IP KVM...