Observations on make release process?

[Clifton Royston]

On Fri, Nov 14, 2003 at 10:48:13PM +0100, Wilko Bulte wrote:
> On Fri, Nov 14, 2003 at 11:37:05AM -1000, Clifton Royston wrote:
> >   Is this as good a list as any for observations on the FreeBSD "make
> > release" process?  I can't see any other list that fits the subject.
> 
> Did you dig into http://www.freebsd.org/releng/#docs ?

Oh yes, that was one of my "bibles" so far, especially 

<http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-build.html>

along with "man release" and some other notes I've found on the web
like:

<http://www.sfc.wide.ad.jp/~watari/FreeBSD/boot.html>

  Here's one minor inaccuracy (or at any rate inadequacy) I've found in
"man release" and the above pages: 

* The "release" man page refers to the release.1 - release.10, ftp.1,
etc. as subtargets of "release".  Actually, they are not proper
subtargets of release and you can't use them like that.  The
release.1-release.10 and similar are instead subtargets of the
dorelease target, a special target which must only be executed in the
chrooted environment and only with a number of environment variables
previously set.

  The "release" and "rerelease" targets both create an "mk" script in
the root for the chroot and then execute it in the chrooted environment
to set a number of variables and make the "dorelease" target.  This
limits the number of things you can set to control the behavior of the
build process to *only* the specific variables documented in the
release man page which the "release" and "rerelease" targets know how
to set in the chrooted /mk script.  Only the "release" and "rerelease"
targets are valid in the normal environment; only the "dorelease"
target and its subtargets are valid in the chrooted release
environment.

  Another really confusing pitfall I ran into:

* Two different copies of cc/gcc get used for different parts of the
release build.  This really had me pulling my hair out as to why some
compiler arguments were being rejected in some parts of the chrooted
build, while they worked fine in others.  Finally I realized that many
makefiles in the kernel-building portion of the release process (not
always building kernel files themselves, and not always invoked with
COPTFLAGS) get invoked with a path which corresponds to
/var/release/usr/obj/usr/src/i386/usr/bin. This isn't mentioned
anywhere that I found, unless I'm just blind.

*  I also ran into some weird interactions from the fact (documented)
that you must do a buildworld outside the chrooted environment first,
and then another one gets done inside the chrooted environment. What's
not documented but seems to be required is that the make configuration
defaults used for these two builds must match (exactly? fairly
closely?) and the latter set of defaults comes out of a fresh CVS
checkout.  Therefore it would seem that if you have a custom
/etc/make.conf file that you are normally building/updating your system
with (e.g. if you have run "use.perl ports") you must move it aside
before doing a buildworld in /usr/src for a "make release", and then
must move it back and clean everything before you next do a regular
buildworld for your system.

* To have the vn portions of the build run properly, if you have not
built vn into your kernel, it would seem the "make release" and "make
rerelease" targets must be run from a normal root shell, not via sudo. 
(I rarely use a root shell, preferring to use sudo.) It would seem that
"sudo make release" should have done it, but whenever I tried that, the
vnconfig step would fail to load the vn module, whereas it would load
if it was run from a separate shell.Again, it took me quite a while of
troubleshooting to figure out that vn worked as root both outside and
inside the chroot environment, but apparently wouldn't work from a
sudo'd make.  I'm completely mystified by that one, as I can't see why
it wouldn't work.

* It would appear with 4.8 that if you don't explicitly set
KERNEL_FLAGS="'COPTFLAGS=-O -pipe'" in the "make release" command, you
end up with a kernel and root file system set that is too big to fit on
a floppy, causing the "make release" to bomb at the boot floppy
creation step.  (I should confirm this by rerunning...)

* There is currently no documentation I've been able to find on how to
remove certain elements from the base system in a release build.  In
particular, what one might try because it "normally" works - namely
setting NOBIND, NOSENDMAIL, etc. in your make configuration variables -
only causes the build process to fail.  However, I hope to puzzle this
out pretty shortly as I think I saw something mentioned about this on
-hackers a while back, and will then add that to my notes.

  Of course, it's possible I have made some errors in some of these
observations.  One problem is that it takes so long to rerun a build
from scratch, it is tempting (and timesaving) to redo from where it
failed with "make rerelease" but in that case it's hard to be sure that
you have consistent results.  Even after thinking I had the process
down 100%, I retried it and failed, which led me to have to do some
more tweaking on the compiler options to correctly deal with my second
point above.

  It also bears mentioning that if you are having errors in the make
process and want to do serious debugging on what's going wrong, you
really *must* do it by chrooting a root shell into the release chroot
environment, and doing all your troubleshooting there.  Trying to
troubleshoot from outside the chroot is likely to mislead you.

  Hopefully if I can put these notes together and get any errors I've
made corrected, it will help others get a head start on this kind of
thing.

  -- Clifton

-- 
          Clifton Royston  --  cliftonr at tikitechnologies.com 
         Tiki Technologies Lead Programmer/Software Architect
Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
  Did you ever milk this kind of cow?  Well we can do it.  We know how.
If you never did, you should.  These things are fun, and fun is good.
                                                                 -- Dr. Seuss