If you get stuck with a cross compile, or one of the more minimal C libraries or very minimal package selection, try building a standard 'no special optimisation, no frills' configuration, first. The major target configurations get build (and therefore tested) by most people and you can get used to T2 before you continue with a more specialized configuration.

If this fails check, the T2 mailing list for messages/queries regarding the failure.

It is useful to configure T2 for writing to terminal whilst doing the build: In ./t2 config select:

[*] Retry building broken packages
[ ] Always clean up src dirs (even on pkg fail)
[*] Print Build-Output to terminal when building

Or just running tail -f on the current log file.

In addition one can run watch in a different terminal on the list of files in build/default-*/root/var/adm/logs:

watch -d ls -lt build/default-*/root/var/adm/logs

Recent versions of T2 support some form of a distributed build in a cluster using distcc and icecream.

For less esoteric setups simply using RAID 0 (striping mode) using two IDE drives over two IDE channels speeds a build up significantly. This is because building packages is IO intensive.

An obvious optimisation is to select a target which builds the fewest packages, exclude building unneeded packages and to skip the final rebuild (stage 9).

If your build process should allow other users to make full use of the system, you can set the nice level to the lowest priority. e.g.

nice -n 19 ./t2 build-target

secures the build process won't saturate the CPU when other users need it (IO resources may be exhausted temporarily though).