The FreeBSD Diary

In my case, I have a fast dual Xeon box, and a much slower 486 box (see "my first" at the bottom right of this page).  When I first did a build world, it took 57 hours on my 486 with 16MB of RAM.  That's not something I'm likely to do very often.  Fortunately, the build world process is divided up nicely into distinct sections which will me to build world on the Xeon, and then install to the 486.

This process uses NFS, so we'll assume you have NFS configured on both boxes. I've configured my Xeon box as an NFS server and my 486 as an NFS client.   Full instructions on how to do these configurations are included in the NFS link above

13 March 2000 - I updated the script file and modified this article accordingly.  Things have changed in the kernel building arena, so I've added KERNCONF to the makefile. For more information on KERNCONF, see the man page for make.conf(5).

I also added three new options to the makefile:

• kernelbuild
• kernelinstall
• cleanlogs

I also changed the format of the log files:

• <action>.YYYY.MM.DD.HH.MM.SS.log

The value of <action> depends on what you did:

Action	Description
update	cvsup results
bw	build world
iw	install world
kernel	build and install kernel
kernelbuild	build kernel
kernelinstall	kernel install
merge	mergemaster

You can also delete the logs with make cleanlogs.

1. Any -D variables defined in the buildworld must also be supplied in the installworld just like the makeworld handbook page says.  In short, any options you use on the make buildworld must also be used on the make installworld.  There will be tears if you don't.
   
2. Don't set CPU specific optimization flags and then do the installworld on a other-than cpu machine.
   
3. Read /usr/src/UPDATING.  It contains the latest information about building.  The information on build world can quickly become dated.

Those are the primary things you should consider.  But some recent talk has been about /etc/make.conf on each box contain similar settings.  Remember to take into account /etc/defaults/make.conf.   Most people will not have to worry about this.  If you have no idea what I'm talking about, then you probably don't need to be concerned.

The other thing to note is that I am using a custom makefile for this process.   You don't have to use this makefile, but I've found it quite useful.  See the Resources section for details on this makefile.  As much as is possible, I will give both sets of commands: the command for my makefile and the command the makefile actually issues.  I use this makefile because it is easy, convenient, saves typing, and automatically creates logs for me.  I normally put this makefile in /root/make but it can reside anywhere.  I merely find that location convenient so I can easily do this:

[dan@xeon:~] $ su -l
Password:
[root@xeon:~] # cd make
[root@xeon:~/make] #

From there, I can issue all the commands which appear in the following sections...unless otherwise stated.

NOTE: I put this makefile on both boxes, the XEON and the 486.  I configured each box accordingly:

• on the XEON box, I put MYKERNEL=XEON
• on the 486, I put MYKERNEL=DUCKY

If you don't set them correctly on each box, you might wind up installing the wrong kernel.  That's no big deal.  Just follow the instructions in the handbook for booting from an alternative kernel.  Here's the short version: press space at the booting countdown, then enter unload, then enter boot kernel.old (or whatever kernel you want; type ls for a list).

I found out how to do this type of install by reading the FreeBSD Handbook (available both online and in book form).  In the handbook, I found this section on make world.   Search the page for a reference to NFS (it's under 19.4.6.4. Version 2.2.5 and above).

[root@xeon:~] # more /etc/exports
/usr/src /usr/obj 192.168.0.20

Note that all exported directories within the same file system must appear on one line.   By default, /usr/src and /usr/obj are on the same file system.

Here are the NFS mounts which I issued on the 486.  These will allow the 486 to see the files on the Xeon.

# mount -v xeon:/usr/src /usr/src
xeon:/usr/src on /usr/src (nfs)
# mount -v xeon:/usr/obj /usr/obj
xeon:/usr/obj on /usr/obj (nfs)

Instead of xeon, you could use the IP address of the server or the name of the box.  Use whatever works and what you normally use.

Remember to create your kernel configuration file first and set the name of this file within the Makefile (see MYKERNEL).

1. su to root
2. cd ~/make
3. make update (updates your sources)
4. make build - does a build world.
5. make kernelbuild MYKERNEL=DUCKY on the fast box
6. make kernelinstall MYKERNEL=DUCKY on the slow box
7. /usr/src/UPDATING recommends a reboot here just to make sure the kernel you just built is operational.  If it is not you can still reboot to kernel.old and still have your world and kernel in sync.  For what it's worth, I don't usually do this reboot.
8. mergemaster -p
9. make install - installs the results of the above builds
10. make merge - merges the configuration file changes
11. reboot

# make update
# make world

These two steps update your source code and does a make world (compiles the base system).  If you were issuing these commands manually, this is what you would type:

# cd /usr/src
# cvsup -g -z -L2 supfile
# make buildworld

where supfile is the name of your cvsup configuration file.

My elapsed time: 2.5 hours.

I suspect it's my disks which are slowing me down.  I know it takes only about an hour on a Pentium III (compared to the dual XEON I have) box a client has.  But I know they have faster disks.

# make kernelbuild MYKERNEL=DUCKY

This assumes the kernel configuration file for the 486 is named DUCKY and has been copied to the XEON box (i.e. /usr/src/sys/i386/conf).

These are the commands you would type manually:

# make buildkernel KERNCONF=DUCKY

Now that doesn't look like much saving on keystrokes, but the script does create a log for you.

Note that I did not do an install.  The above commands were issued on the Xeon, not the 486.  The install will be done on the 486.

My elapsed time: 18  minutes.

# make kernelinstall MYKERNEL=DUCKY

Remember: this directory actually resides on the XEON, because of the NFS mount.   But it will install the kernel on the 486.

The manual command for this is:

# cd /usr/src
# make installkernel

My elapsed time: 2 minutes.

# make install

Actually, I had the make world script on the 486, so all I did, as root, was cd ~/make ; make install.

The manual commands would be:

# cd /usr/src
# make installworld

My elapsed time: 30 minutes.

Since this was a production box, I actually did a nice 15 make install so that it ran at a lower priority.

# cd ~/make
# make merge

If you're not using my script, I suggest you follow the normal mergemaster instructions for upgrading.  But here's the extract from my makefile:

# mergemaster -w 120 -t

My elapsed time: 10 minutes.

Note: I do remember a problem with /etc/pam.conf.  This may have been my fault, but I didn't get the new file during the upgrade.  I may have screwed up with my merge.  The symptoms turned up when I tried to used SSH.   Sorry, but I didn't record the details.  I think it had to do with system keys being in a different format.

--------------------------------------------------------------
>>> Installing everything..
--------------------------------------------------------------
cd /usr/src; make -f Makefile.inc1 install
===> share/info
===> include
creating osreldate.h from newvers.sh
setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh; echo "$COPYRIGHT" > osreldate.h;
echo "#ifdef _KERNEL" >> osreldate.h; echo '#error "osreldate.h must not be used in the kernel, use sys/param.h"' >> osreldate.h; echo "#else"
>> osreldate.h; echo \#'undef __FreeBSD_version' >> osreldate.h; echo \#'define __FreeBSD_version' $RELDATE >> osreldate.h; echo "#endif"
>> osreldate.h
touch: not found
*** Error code 127

Stop in /usr/src/include.
*** Error code 1

Stop in /usr/src.
*** Error code 1

I solved the problem by mounting the NFS volumes and trying again. On the slow box, I actually had a fully populated /usr/src and /usr/obj from a previous build world. When I first saw this error, I thought it was caused by the clocks on the two boxes not being set to the same time. After fixing that issue, the problem still occurred. It wasn't until later that I noticed I had not remounted the NFS volumes.