sysinstall install.cfg
vrwmiller at gmail.com
vrwmiller at gmail.com
Thu Nov 11 18:32:37 UTC 2010
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
More information about the freebsd-questions
mailing list