Date: Thu, 26 Jan 2012 04:30:04 GMT From: Devin Teske <devin.teske@fisglobal.com> To: freebsd-sysinstall@FreeBSD.org Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as installer option Message-ID: <201201260430.q0Q4U48b021911@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/164281; it has been noted by GNATS. From: Devin Teske <devin.teske@fisglobal.com> To: CeDeROM <cederom@tlen.pl> Cc: <bug-followup@freebsd.org>, Devin Teske <devin.teske@fisglobal.com> Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as installer option Date: Wed, 25 Jan 2012 20:28:50 -0800 On Jan 25, 2012, at 2:02 PM, CeDeROM wrote: > Hello Devin and thank you for your response! :-) >=20 You're welcome ^_^ > Having that option would be great, unless its too much work to prepare > two separate install methods if you say they need different boot > method. It's not hard at all. I have a very elegant solution for separating the nam= espaces. This involves chroot'ing bsdinstall into it's own ISO-9660 namespace, where= it: 1. can bootstrap a traditional /etc/rc 2. have full access to 100+ binaries, and 3. unpacks *.txz files from /usr/freebsd-dist/ opposed to sysinstall which can be separated into it's own namespace, where 1. there is no /etc/rc-style bootstrap and init simply executes /stand/sysi= nstall directly 2. the only binaries available are those in the 1.9MB mfsroot.gz loaded by = loader(8), and 3. it unpacks split-tgz dists from the CD-ROM media it booted from The chroot'ing mentioned is accomplished by using DruidBSD, which is: a. the above-mentioned "1.9MB mfsroot.gz", designed to... b. boot the user into a read-write (albeit limited to ~700K usable space) m= emory filesystem c. Use the ISO09660 geom provider to re-mount /dev/iso9660/druid to /cdrom d. Bootstrap additional executables into PATH based in /cdrom/freebsd/rescue e. Configure shared object support for /cdrom/freebsd/rescue/lib f. Provide the user with a BASH shell I'll simply create a custom build of DruidBSD that swaps that last step for= calling "chroot /cdrom/freebsd/bsdinstallroot /bin/sh /etc/rc" rather than= calling "/cdrom/freebsd/rescue/bash". Then, the boot-loader menu will simply be (on the underside) swapping-out m= fsroot's (sysinstall's instead of the shim-one created to bootstrap the use= r into the bsdinstall root). It may sound complicated, but the shim actually has a very important advant= age (explained below in your quest to understand the pro's-versus-con's bet= ween these two diametrically-apposed boot-procedures. > I was told bsdinstall replaced sysinstall because it has new > features unavailable to sysinstall and its better to maintain. Now I > also see more about their difference and that it is not possible to > simply put bsdinstall as sysinstall option. I can understand that > change and I can understand this makes no bigger sense to develop both > of the installers anymore at the same time as they work in a totally > different way from system perspective and if the bsdinstall is really > better. It's not so much as "better" as it is "different". I'm actually proposing a third-option which marries the two to create somet= hing better than both (creating an-overall easier-to-maintain system). Using the mfsroot to pre-bootstrap the normal-execution-style (mimicking tr= aditional boot) of bsdinstall (which I definitely approve of -- more on tha= t below) actually better-enables bsdinstall to run in a more-natural LiveCD= environment. ASIDE (the "more on that below" part): The fact that bsdinstall boots into a LiveCD environment makes it what I te= rm a "new-style installer" (which is a great thing). In my mind, a fancy gr= aphical installer doesn't itself define a "new-style installer" but instead= by-definition I mean that there has been a merger between "LiveCD" functio= nality and "Installer" functionality. A new-style installer actually bootst= raps a natural environment directly from the CD-ROM and actually appears li= ke an installed system when observing the ISO-9660 directory structure. Thi= s means the user has the ability to (a) run diskless, and/or (b) play befor= e optionally (c) installing -- all without rebooting. From the systems arch= itecture/developer angle, it's even greater that installation is not necess= ary to easily probe hardware, poke drivers, test kernels, etc. There's only one problem with the current method of marrying the LiveCD/Ins= taller environments -- booting a traditional system requires a writable fil= esystem so a simple "make installworld" to the ISO-9660 directory root is o= ut of the question. This is where the shim mfsroot comes in to save the day. Currently-developed is an mfsroot specifically focused on breaking out of t= he mfsroot structure and re-rooting into the ISO-9660 structure using the G= EOM layer. This today can be used to bootstrap into the bsdinstall install environment= and provide an identical experience to what bsdinstall provides today as-p= rovided by 9.0-RELEASE media However, this can be enhanced to make it possible to do that "make installw= orld" to the ISO-9660 structure ... making that LiveCD/Installer look even = more like a true LiveCD (that is, making it look even more like an installe= d system that the user can play in). Currently not-yet developed but _could_ be easily done is to use that pre-b= ootstrap process of the mfsroot to do the following: 1. Mount the ISO-9660 GEOM layer 2. load tmpfs.ko (provided on hypothetical enhanced mfsroot) 3. load unionfs.ko (provided on hypothetical enhanced mfsroot) 4. Create a small (10MB? 100MB?) tmpfs area to write to 5. Layer the tmpfs writable area onto the ISO-9660 layer creating a "writab= le ISO-9660 structure" 6. chroot into ISO-9660 structure where we boot a natural system that forks= -off to bsdinstall (which asks if you want to continue to multi-user mode [= which it doesn't-yet, it just simply offers to start a shell], where the us= er can re-invoke the installer anytime by executing bsdinstall). End ASIDE. > Right now this is clear for me those are two different > programs based on two different mechanisms. I was just suprised > bsdinstall was passed and replaced the good installer without > implementing existing sysinstall functionalities first (i.e. does not > allow to perform fresh install over existing one, set installation > options, choose media before commit, etc), and this is very important > from user perspective. With the way things were going with RC3, a lot of us were under the impress= ion that 9.0-RELEASE would use sysinstall and bsdinstall would be pushed ba= ck to 9.1 for use on media. > Now its already in production, so it should > develop rapidly and bring the good sysinstall functionalities again > soon :-) >=20 Because the changes that I'm proposing are deep, require long-discussions, = and are sweeping... I'm releasing a forked installer and will be looking for feedback. The feedback will hopefully help shape the direction that affect not only t= he installer but release engineering. > Btw. are there any comparison documents/articles between > functionalities of old boot method used by sysinstall and the new boot > method used by bsdinstall to see the advantages of the new method? :-) >=20 See above. > Best regards! :-) > Tomek Thanks! --=20 Devin _____________ 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?201201260430.q0Q4U48b021911>