DragonFly boot2 - moved out of commits thread

[Bill Hacker]

7d at crater_reader.dragonflybsd.org> <0dd1b0cf082835565b33dce726a5a278.squirrel at www.shiningsilence.com>
In-Reply-To: <0dd1b0cf082835565b33dce726a5a278.squirrel at www.shiningsilence.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 70
Message-ID: <49af6c9a$0$880$415eb37d at crater_reader.dragonflybsd.org>
NNTP-Posting-Host: 61.10.57.144
X-Trace: 1236233371 crater_reader.dragonflybsd.org 880 61.10.57.144
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:
> 
> http://www.dragonflybsd.org/images/
> 
> 
> 
> 

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 
then....

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...

In use:

nextboot <device,[slice|partition]>

. .. 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...

Or NOT.

JM2CW, but long-term, it could be cheaper than an IP KVM...

Bill