Date: Thu, 11 Nov 2010 18:32:34 +0000 From: vrwmiller@gmail.com To: Devin Teske <dteske@vicor.com> Cc: freebsd-questions@freebsd.org Subject: Re: Re: sysinstall install.cfg Message-ID: <0016e644c7c895e6920494cb3215@google.com> In-Reply-To: <1289495940.30235.51.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
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@vicor.com> wrote: > On Thu, 2010-11-11 at 12:12 +0000, vrwmiller@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0016e644c7c895e6920494cb3215>