Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Oct 2012 16:20:59 -0700
From:      Devin Teske <devin.teske@fisglobal.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        Garrett Cooper <yanegomi@gmail.com>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Devin Teske <dteske@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: New Boot Loader Menu
Message-ID:  <338616C0-F1EC-409B-B044-ADBB62ECFE38@fisglobal.com>
In-Reply-To: <5072033A.4090308@freebsd.org>
References:  <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <86k3v21qsx.fsf@ds4.des.no> <3EB58454-7820-43C4-911E-7DEF2D02C880@fisglobal.com> <86fw5q15f9.fsf@ds4.des.no> <D61F7ED5-76C3-453D-878A-F0C678198C87@fisglobal.com> <A5FE9B8C-742B-45E0-85EB-1092A7D58D04@gmail.com> <5071EAB2.4060003@freebsd.org> <DA8D6935-039D-4228-ABB6-59F43398D2F8@fisglobal.com> <5072033A.4090308@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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

> On 10/7/12 2:10 PM, Devin Teske wrote:
>>=20
>> On Oct 7, 2012, at 1:48 PM, Julian Elischer wrote:
>>=20
>>> 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 be=
fore investing too much time in a direction that doesn't bear a lot of frui=
t. I'm sure others here agree.
>>> It'd be interesting to see if we could get a boot loader that has an op=
tion to boot a backup
>>> image, or maybe off network.. I know that by the time we got this far w=
e are supposed to be
>>> beyond that, but who knows what is actually possible.
>>>=20
>>> I'd love to see a picoBSD image available for booting in emergencies. W=
hether in it's own partition,
>>> or just a file in the root partition (or wherever) that can be loaded a=
s a root filesystem.
>>> having the ability to recover from really bad screwups is why you need =
the menus in the first place usually.
>>>=20
>>> not sure what is really possible.
>>>=20
>>=20
>> *huge smiles*
>>=20
>> Have you been talking to old VICORians about what I've been working on h=
ere? haha
>>=20
>> It's like you stole a page out of my playbook.
>>=20
>> I've been working on this for years (slowly making the infrastructure ch=
anges in DruidBSD to accommodate this, and         slowly trying to work th=
at code back into FreeBSD).
>>=20
>> 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 Pic=
oBSD.
>=20
> Pico, or Nano?
> I know that Pico no longer fits on a single floppy but it's still pretty =
damned small.
>=20

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 assembl=
ed, it's still under 24MB (tho I could make that much smaller if I really w=
anted).

Funny story:
Our company handed out 32MB (!!) thumb drives a couple years ago (yes, in 2=
010 !! they handed out 32MB !! thumb drives). Being almost completely usele=
ss for any other means, I decided (no, _set out_) to create the _most_ usef=
ul boot device possible from these paltry 32MB storage devices (which other=
wise 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 ves=
amenu com32 module) -- all still under the 32MB mark.

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

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


>>=20
>> In the past month, I used DruidBSD maybe 5-dozen times to rescue an unbo=
otable system. Which system? the system I was developing the boot loader on=
 (haha).
>=20
> 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 t=
o have an external device (with it's own copy of the boot files -- as in su=
ch situations, you really can't trust _anything_ in /boot so you'd _want_ t=
he 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 tim=
es-of-need
b. a small, tiny ISO with the same rescue scripts as rescue_mfsroot.gz in t=
imes-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/vi=
ewvc/druidbsd/druidbsd/druid/src/freebsd/menu/scripts/repair?revision=3D1.2=
&view=3Dmarkup for the actual script I'm talking about)

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

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



>>=20
>> Everytime I would make a mistake (and subsequently end up in BTX halt, p=
anic 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 mi=
stake and have a working system again.
>=20
> 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 mig=
ht be enough.
> (keep it in an envelope taped to the side of the machine :-).
>=20

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

A lot of DruidBSD is all about building a better/smarter install platform t=
hat has integrated automation, rescue, and cloning abilities. I'd really li=
ke 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 me=
dia, 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 sam=
e 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 ac=
hieve this. However it's going to be a long process.

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

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

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


>>=20
>> 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 Repa=
ir Shell" and answer guided questions to create a working environment copac=
etic 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 r=
eal 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=
..
>=20

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 cur=
rently _must_ use a whole extra CD because the "rescue_mfsroot.gz" hasn't b=
een published "in the raw" (but if you dig in CVSweb you can download it di=
rectly for inspection).
--=20
Devin




>>=20
>> 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 (t=
his one screenshot taken 3 years ago):
>>=20
>> http://twitpic.com/16spp2
>>=20
>> --=20
>> Devin
>> _____________
>> The information contained in this message is proprietary and/or confiden=
tial. 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 aw=
are that any message addressed to our domain is subject to archiving and re=
view by persons other than the intended recipient. Thank you.
>=20

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?338616C0-F1EC-409B-B044-ADBB62ECFE38>