bin/164281: bsdinstall(8): please allow sysinstall as installer option

[Devin Teske]

The following reply was made to PR bin/164281; it has been noted by GNATS.

From: Devin Teske <devin.teske at fisglobal.com>
To: CeDeROM <cederom at tlen.pl>
Cc: <bug-followup at freebsd.org>, Devin Teske <devin.teske at 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.