New Boot Loader Menu

Sun Oct 7 23:21:07 UTC 2012

On Oct 7, 2012, at 3:33 PM, Julian Elischer wrote:

> On 10/7/12 2:10 PM, Devin Teske wrote:
>> 
>> On Oct 7, 2012, at 1:48 PM, Julian Elischer wrote:
>> 
>>> On 10/7/12 12:52 PM, Garrett Cooper wrote:
>>>> I'd like to see sketches or a general idea of what you have in mind before investing too much time in a direction that doesn't bear a lot of fruit. I'm sure others here agree.
>>> It'd be interesting to see if we could get a boot loader that has an option to boot a backup
>>> image, or maybe off network.. I know that by the time we got this far we are supposed to be
>>> beyond that, but who knows what is actually possible.
>>> 
>>> I'd love to see a picoBSD image available for booting in emergencies. Whether in it's own partition,
>>> or just a file in the root partition (or wherever) that can be loaded as a root filesystem.
>>> having the ability to recover from really bad screwups is why you need the menus in the first place usually.
>>> 
>>> not sure what is really possible.
>>> 
>> 
>> *huge smiles*
>> 
>> Have you been talking to old VICORians about what I've been working on here? haha
>> 
>> It's like you stole a page out of my playbook.
>> 
>> I've been working on this for years (slowly making the infrastructure changes in DruidBSD to accommodate this, and         slowly trying to work that code back into FreeBSD).
>> 
>> NOTE: DruidBSD at it's core (when it's not being re-purposed as a multi-media FreeBSD universal installation platform) is actually smaller than PicoBSD.
> 
> Pico, or Nano?
> I know that Pico no longer fits on a single floppy but it's still pretty damned small.
> 

The DruidBSD core image is a 1.9MB gzip-compressed floppy image (mfsroot.gz).

NOTE: Of course, that doesn't include a kernel. When you get it all assembled, it's still under 24MB (tho I could make that much smaller if I really wanted).

Funny story:
Our company handed out 32MB (!!) thumb drives a couple years ago (yes, in 2010 !! they handed out 32MB !! thumb drives). Being almost completely useless for any other means, I decided (no, _set out_) to create the _most_ useful boot device possible from these paltry 32MB storage devices (which otherwise would have ended up in the trash). I successfully loaded DruidBSD _and_ about 10 other great tools onto it (including memtest, windiag, memtest+, seatools, dban, firmware updates, hdt, spinrite, tuff-test pro, and more); everything easily usable with a graphical menu (using ISOLINUX and the vesamenu com32 module) -- all still under the 32MB mark.

An earlier version (sans corporate property, of course, such as spinrite and tuff-test pro enterprise-licensed copies) can be downloaded here:

http://druidbsd.sourceforge.net/download.shtml#DruidBSD

>> 
>> In the past month, I used DruidBSD maybe 5-dozen times to rescue an unbootable system. Which system? the system I was developing the boot loader on (haha).
> 
> so, the question is, were does the boot come from and where does it load the image from?  usb-key?

I'd recommend keeping it in /boot

However, for situations where you can't trust /boot you really would want to have an external device (with it's own copy of the boot files -- as in such situations, you really can't trust _anything_ in /boot so you'd _want_ the external device to be your boot device with its own pristine copies).

I'd say FreeBSD could use both:
a. menu system that can load (for example) a /boot/rescue_mfsroot.gz in times-of-need
b. a small, tiny ISO with the same rescue scripts as rescue_mfsroot.gz in times-of-need when /boot can't be trusted

For (b) above, sure we have "-bootonly" media, but it's not imbued with any scripts like what DruidBSD has (see http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/src/freebsd/menu/scripts/repair?revision=1.2&view=markup for the actual script I'm talking about)

Rather, for (b) I'm talking about having an ISO that anybody in-need can download where said ISO is (a) small (b) built for rescue duty of any hardware in any shape.

Of course, there's no reason why the -bootonly media couldn't _become_ that rescue disc with a little work.

>> 
>> Everytime I would make a mistake (and subsequently end up in BTX halt, panic free guard1, or other fatal condition), I simply reboot, boot DruidBSD, and within 3 keystrokes I have my system mounted read-write with all the tools I need to fix it. In less than 20 seconds, I've often corrected my mistake and have a working system again.
> 
> to some extent I'd like to see some recoverability like this for default freeBSD. even the old "create a bootable usb fixit-key"  during install might be enough.
> (keep it in an envelope taped to the side of the machine :-).
> 

Definitely on the radar. I've even talked (briefly) with jpaetzel about this.

A lot of DruidBSD is all about building a better/smarter install platform that has integrated automation, rescue, and cloning abilities. I'd really like to see FreeBSD's installer (whatever that may be; currently bsdinstall) embrace some of the pc-sysinstall features that jpaetzel and I talked about in our last meeting. Such as the ability to boot a system from external media, run a tool to detail the filesystem configuration, and then save that config to a file for later use (either in setting up a machine with the same characteristics or as a means of rescuing the same box in trying times).

My plan is to (some day) hunker down and use bsdinstall and bsdconfig to achieve this. However it's going to be a long process.

Part of this long process is going to be the enhancements to the loader menu that this thread has talked so much about. Another large part of this process is going to be simply bringing back the ability to use an mfsroot (something that was lost-in-transition from 8 to 9).

There are a LOT of systemic things that need to be broached before we can get to the promised land of integrated rescue (I've even envisaged the changes necessary at the release engineering level).

But, … for now, DruidBSD is there for all of us to lean-on (and I'll continue to release new/more-interesting DruidBSD products -- such as the micro-rescue-image we're talking about here).

>> 
>> NOTE: You can try it out yourself. I made publicly-available the latest version recently as part-of the FreeBSD-9.0_Druid-1.0b57.iso up on druidbsd.sf.net (boot the ISO, select "freebsd", then select "Interactive Disk Repair Shell" and answer guided questions to create a working environment copacetic to fixing even the worst situations). It even has a mode where it will start SSHD from the boot media so that *someone-ELSE* can log in remotely and fix your non-bootable system (which we've had to use before -- it's a real life-saver when someone in Manila for example has no FreeBSD knowledge but can at least boot a system with a CD and answer some basic questions).
> true, though I'd like to see if it can be done without the whole extra CD..
> 

Right-o. I'm telling people in the above, that if they want to try out this "rescue functionality" (which _doesn't_ require a whole extra CD) they currently _must_ use a whole extra CD because the "rescue_mfsroot.gz" hasn't been published "in the raw" (but if you dig in CVSweb you can download it directly for inspection).
-- 
Devin

>> 
>> Here's a screenshot that shows that DruidBSD has had the ability to swap out the root filesystem image with a "rescue image" for nearly a decade (this one screenshot taken 3 years ago):
>> 
>> http://twitpic.com/16spp2
>> 
>> -- 
>> Devin
>> _____________
>> The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
> 

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.