Building &os; Installation MediaThis section describes the general procedures producing &os;
development snapshots and releases.Release Build ScriptsThis section describes the build scripts used by &team.re;
to produce development snapshots and releases.The release.sh ScriptPrior to &os; 9.0-RELEASE,
src/release/Makefile was updated to
support &man.bsdinstall.8;, and the
src/release/generate-release.sh script
was introduced as a wrapper to automate invoking the
&man.release.7; targets.Prior to &os; 9.2-RELEASE,
src/release/release.sh was introduced,
which heavily based on
src/release/generate-release.sh included
support to specify configuration files to override various
options and environment variables. Support for configuration
files provided support for cross building each architecture
for a release by specifying a separate configuration file for
each invocation.As a brief example of using
src/release/release.sh to build a single
release in /scratch:&prompt.root; /bin/sh /usr/src/release/release.shAs a brief example of using
src/release/release.sh to build a single,
cross-built release using a different target directory, create
a custom release.conf containing:# release.sh configuration for powerpc/powerpc64
CHROOTDIR="/scratch-powerpc64"
TARGET="powerpc"
TARGET_ARCH="powerpc64"
KERNEL="GENERIC64"Then invoke src/release/release.sh
as:&prompt.root; /bin/sh /usr/src/release/release.sh -c $HOME/release.confSee &man.release.7; and
src/release/release.conf.sample for more
details and example usage.The thermite.sh Wrapper
ScriptIn order to make cross building the full set of
architectures supported on a given branch faster, easier, and
reduce human error factors, a wrapper script around
src/release/release.sh was written to
iterate through the various combinations of architectures and
invoke src/release/release.sh using
a configuration file specific to that architecture.The wrapper script is called
thermite.sh, which is available in the
&os; Subversion repository at
svn://svn.freebsd.org/base/user/gjb/thermite/,
in addition to configuration files used to build
&branch.head; and &branch.stablex; development
snapshots.Using thermite.sh is covered in and .Each architecture and individual kernel have their own
configuration file used by release.sh.
Each branch has its own defaults-X.conf
configuration which contains entries common throughout each
architecture, where overrides or special variables are set
and/or overridden in the per-build files.The per-build configuration file naming scheme is in the
form of
${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf,
where the uppercase variables are equivalent to what
&man.make.1; uses in the build system, and lowercase variables
are set within the configuration files, mapping to the major
version of the respective branch.Each branch also has its own
builds-X.conf configuration, which is
used by thermite.sh. The
thermite.sh script iterates through each
${revision}, ${TARGET_ARCH},
${KERNCONF}, and ${type} value, creating
a master list of what to build. However, a given
combination from the list will only be built if the
respective configuration file exists, which is where the
naming scheme above is relevant.There are two paths of file sourcing:builds-12.conf
-> main.confThis controls thermite.sh
behavior12-amd64-GENERIC-snap.conf
->
defaults-12.conf
-> main.confThis controls release/release.sh
behavior within the build &man.chroot.8;The
builds-12.conf,
defaults-12.conf,
and main.conf configuration files exist
to reduce repetition between the various per-build
files.Building &os; Development SnapshotsThe official release build machines have a specific
filesystem layout, which using ZFS,
thermite.sh takes heavy advantage of with
clones and snapshots, ensuring a pristine build
environment.The build scripts reside in /releng/scripts-snapshot/scripts
or /releng/scripts-release/scripts
respectively, to avoid collisions between an
RC build from a releng branch versus
a STABLE snapshot from the respective stable
branch.A separate dataset exists for the final build images,
/snap/ftp. This
directory contains both snapshots and releases directories.
They are only used if the EVERYTHINGISFINE
variable is defined in main.conf.The EVERYTHINGISFINE variable name was
chosen to avoid colliding with a variable that might be
possibly set in the user environment, accidentally enabling
the behavior that depends on it being defined.As thermite.sh iterates through the
master list of combinations and locates the per-build
configuration file, a ZFS dataset is created
under /releng, such as
/releng/12-amd64-GENERIC-snap.
The src/, ports/, and
doc/ trees are checked out to separate
ZFS datasets, such as /releng/12-src-snap, which are
then cloned and mounted into the respective build datasets.
This is done to avoid checking out a given tree more than
once.Assuming these filesystem paths,
thermite.sh would be invoked as:&prompt.root; cd /releng/scripts-snapshot/scripts
&prompt.root; ./setrev.sh -b &branch.stablex;
&prompt.root; ./zfs-cleanup.sh -c ./builds-12.conf
&prompt.root; ./thermite.sh -c ./builds-12.confOnce the builds have completed, additional helper scripts
are available to generate development snapshot emails which are
sent to the freebsd-snapshots@freebsd.org
mailing list:&prompt.root; cd /releng/scripts-snapshot/scripts
&prompt.root; ./get-checksums.sh -c ./builds-12.conf | ./generate-email.pl > snapshot-12-mailThe generated output should be double-checked for
correctness, and the email itself should be PGP signed,
in-line.These helper scripts only apply to development snapshot
builds. Announcements during the release cycle (excluding the
final release announcement) are created from an email
template. A sample of the email template currently used can
be found here.Building &os; ReleasesSimilar to building &os; development snapshots,
thermite.sh would be invoked the same way.
The difference between development snapshots and release builds,
BETA and RC included, is
that the &man.chroot.8; configuration files must be named with
release instead of snap as
the "type", as mentioned above.In addition, the BUILDTYPE and
types must be changed from
snap to release in
defaults-12.conf
and
builds-12.conf,
respectively.When building BETA,
RC, and the final RELEASE,
also statically set BUILDSVNREV to the
revision on the branch reflecting the name change,
BUILDDATE to the date the builds are started
in YYYYMMDD format. If the
doc/ and ports/ trees have
been tagged, also set PORTBRANCH and
DOCBRANCH to the relevant tag path in the
Subversion repository, replacing HEAD with
the last changed revision. Also set
releasesrc in
builds-12.conf
to the relevant branch, such as &branch.stablex; or
&branch.relengx;.During the release cycle, a copy of
CHECKSUM.SHA512 and
CHECKSUM.SHA256 for each architecture are
stored in the &team.re; internal repository in addition to being
included in the various announcement emails. Each
MANIFEST containing the hashes of
base.txz, kernel.txz,
etc. are added to
misc/freebsd-release-manifests in the Ports
Collection, as well.In preparation for the release build, several files need to
be updated:File to EditWhat to Changesys/conf/newvers.shUpdate the BRANCH value to
RELEASEUPDATINGAdd the anticipated announcement datelib/csu/common/crtbrand.cReplace __FreeBSD_version with
the value in
sys/sys/param.hAfter building the final RELEASE, the
&branch.relengx; branch is tagged as &branch.releasex; using the
revision from which the RELEASE was built.
Similar to creating the &branch.stablex; and &branch.relengx;
branches, this is done with svn cp. From the
repository root:&prompt.user; svn cp ^/&branch.relengx;@r306420 &branch.releasex;
&prompt.user; svn commit &branch.releasex;