sysinstall install.cfg

[vrwmiller at gmail.com]

Wow! Thanks for all the info and the time you spent pulling it together and  
writing it out, Devin! There is a lot to digest. Right now, I do have  
a "workaround" that I am currently testing out. I will be hanging onto your  
email for future reference, certainly.

On Nov 11, 2010 12:19pm, Devin Teske <dteske at vicor.com> wrote:
> On Thu, 2010-11-11 at 12:12 +0000, vrwmiller at gmail.com wrote:

> > Hi all,

> >

> > Hoping that someone might be able to help me here. I dynamically  
> generate

> > much of the install.cfg by running scripts that send output to files  
> that

> > are, in turn, loaded into install.cfg utilizing loadConfig. The scripts

> > that are run are placed into the mfsroot in /stand and /. They send the

> > output to /a.

> >

> > I do this twice before the installCommit and both scripts run and load  
> the

> > resulting configs successfully. I also run another script after the

> > InstallComit...it fails citing the script could not be found.



> Before distExtractAll is called (called implicitly by installCommit if

> not previously called), this is the layout of your environment:



> / -- your mfsroot

> /mnt -- your newly formatted disk (empty at this time)

> /mnt/dist -- your install media (beit CD/DVD, NFS, etc.)



> Meanwhile, _after_ distExtractAll (or installCommit in your case), you

> are chroot(2)'ed into /mnt, so this is now your environment:



> / -- your newly formatted disk (populated with FreeBSD now)

> /dist -- your install media







> > In troubleshooting, I found that sysinstall is removing /stand



> That's right:

> http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/sysinstall/install.c.diff?r1=1.360;r2=1.361;f=h



> That change was made 5 years, 9 months ago.





> > and doing other

> > stuff to / and /var. So, I know why the script cannot be found...because

> > sysinstall is removing it.

> >

> > The question I have then is how can I get around this? I attempted  
> putting

> > the script above the installCommit, but the functions being performed  
> here

> > require that the base system already be in place (I'm adding packages).  
> It

> > seems that I have little choice, but to have this after the  
> installCommit.

> > Unfortunately, sysinstall wipes it out.

> >

> > Any guidance is greatly appreciated.



> You essentially have about 5 options (I'll let you choose):



> 1. You can patch sysinstall to keep `/stand' around.

> 2. You can use an older mfsroot containing an older build of sysinstall

> which doesn't blow away `/stand' (not recommended)

> 3. You can switch using pc-sysinstall (as mentioned by krad)

> 4. You can create a "post_install.cfg" in the install media and have

> your call loadConfig on `/dist/post_install.cfg' after installCommit

> 5. You can use an mfsroot already tailored specifically to your needs

> available at http://druidbsd.sf.net/



> Let's look at each option in detail:



> ============================================================



> 1. If you want to patch sysinstall to keep `/stand' around, here's what

> you need to do:



> a. cvsup the FreeBSD source tree (beyond the scope of this e-mail)

> b. Apply the below patch



> --- /usr/src/usr.sbin/sysinstall/install.c 2010-11-11 03:05:53.000000000  
> -0800

> +++ /usr/src/usr.sbin/sysinstall/install.c.orig 2010-06-13  
> 19:09:06.000000000 -0700

> @@ -906,6 +906,9 @@ installFixupBase(dialogMenuItem *self)

> /* BOGON #5: aliases database not built for bin */

> vsystem("newaliases");



> + /* BOGON #6: Remove /stand (finally) */

> + vsystem("rm -rf /stand");

> +

> /* Now run all the mtree stuff to fix things up */

> vsystem("mtree -deU -f /etc/mtree/BSD.root.dist -p /");

> vsystem("mtree -deU -f /etc/mtree/BSD.var.dist -p /var");



> c. Compile a new mfsroot containing your patched sysinstall by:

> i. cd /usr/src

> ii. make buildworld

> iii. cd /usr/src/release

> iv. make release CHROOTDIR=/usr/release EXTSRCDIR=/usr/src \

> NODOC=YES NO_FLOPPIES=YES NOCDROM=YES NOPORTS=YES



> NOTE: If the `make release' fails, it can be resumed...

> i. cd /usr/src/release

> ii. make rerelease CHROOTDIR=/usr/release EXTSRCDIR=/usr/src \

> NODOC=YES NO_FLOPPIES=YES NOCDROM=YES NOPORTS=YES \

> RELEASENOUPDATE=YES



> d. Your mfsroot is at `/usr/release/R/stage/mfsroot/mfsroot.gz'



> NOTE: If, after a successful release, you want to change re-build

> your mfsroot, you really ought to only re-do the `make release'

> step. However, that can be lengthy. If you want to patch only a

> single file and rebuild, you need to first copy the modified

> files from `/usr/src' to `/usr/release/usr/src' (for example,

> copy `/usr/src/usr.sbin/sysinstall/install.c' to

> `/usr/release/usr/src/usr.sbin/sysinstall/install.c') and then:

> i. rm -f /usr/release/usr/obj/usr/src/release/release.4

> ii. rm -f /usr/release/usr/obj/usr/src/release/release.8

> iii. cd /usr/src/release

> iv. make rerelease CHROOTDIR=/usr/release \

> EXTSRCDIR=/usr/src NODOC=YES NO_FLOPPIES=YES \

> NOCDROM=YES NOPORTS=YES RELEASENOUPDATE=YES



> NOTE: If it looks like you're going to go this route, please keep

> reading. The last suggestion is to use my DruidBSD platform which

> already has such patches applied, compiled, and ready to download.



> ============================================================



> 2. Using an older mfsroot that keeps `/stand' around after installCommit

> is neither recommended nor warranted in this case.



> You'd have to go back pretty far. The FreeBSD-4.11 mfsroot contains a

> sysinstall(8) binary that keeps `/stand' around. From looking at CVS, it

> would also appear that the head of the 5.x series also retains `/stand'.

> However, it appears that 6.0 or higher will not fit your needs.



> This has the rather unfortunate side-effect of not being able to support

> installation onto UFS2 -- as you need later sysinstall(8) and mfsroot to

> support performing newfs(8) with the `-O2' option to format the target

> disk in UFS2 versus UFS1.



> This suggestion is not really an option.



> ============================================================



> 3. You can switch to using pc-sysinstall (the PC-BSD installation

> software).



> Unfortunately, this suggestion could potentially require a rewrite of

> your installation script(s) (depending on the content of your scripts).



> This could potentially be akin to a ground-up rewrite.



> ============================================================



> 4. Use a post_install.cfg that lives in your install-media.



> This is by-far the simplest suggestion.



> Let's say that your installation media is CD-ROM, NFS, or Local

> directory. Since your installation media is still accessible in the

> chroot(2)'ed environment (under `/dist'), anything you put in there will

> work surely exist after the installCommit is performed.



> Simply add this:



> configFile=/dist/post_install.cfg

> loadConfig



> after your call to `installCommit'. After the `installCommit' resword is

> processed, the above will be performed except this time (being chroot

> (2)'ed into our new install environment as described at the beginning of

> this e-mail) we will find the `post_install.cfg' file in the

> installation media within the `/dist' mounted-directory.



> ============================================================



> 5. You can use the mfsroot.gz file from my project, which:



> a. Has a patched sysinstall(8) that keeps `/stand' around.

> b. Supports directory-based installation (mediaSetNullFS)

> c. Has many additional utilities not available in the normal mfsroot



> Give it a try... (download via CVS pserver access -- though you can just

> as easily use the below URL to grab the mfsroot and customize it).



> http://druidbsd.sourceforge.net/



> http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druidbsd/mdroot/boot/mfsroot.gz?revision=1.1.1.1



> Alternatively, though...



> You could just base your project off of my project. If you did, your

> installer would support booting off of USB media. The docs are worth a

> read.

> --

> Cheers,

> Devin Teske



> -> CONTACT INFORMATION
> Business Solutions Consultant II

> FIS - fisglobal.com

> 510-735-5650 Mobile

> 510-621-2038 Office

> 510-621-2020 Office Fax

> 909-477-4578 Home/Fax

> devin.teske at fisglobal.com



> -> LEGAL DISCLAIMER
> This message contains confidential and proprietary information

> of the sender, and is intended only for the person(s) to whom it

> is addressed. Any use, distribution, copying or disclosure by any

> other person is strictly prohibited. If you have received this

> message in error, please notify the e-mail sender immediately,

> and delete the original message without making a copy.



> -> END TRANSMISSION