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>