Date: Fri, 14 Nov 2003 12:57:19 -1000 From: Clifton Royston <cliftonr@tikitechnologies.com> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: hackers@freebsd.org Subject: Re: Observations on make release process? Message-ID: <20031114125719.E5759@tikitechnologies.com> In-Reply-To: <20031114214813.GA8188@freebie.xs4all.nl>; from wkb@freebie.xs4all.nl on Fri, Nov 14, 2003 at 10:48:13PM %2B0100 References: <20031114113705.D5759@tikitechnologies.com> <20031114214813.GA8188@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031114125719.E5759>