NAME
release
—
building an
OpenBSD release
DESCRIPTION
There are several steps necessary to build a system release. They are:
- Update sources.
- Build and install a new kernel.
- Build a new system.
- Make and validate the system release.
- Build and install xenocara.
- Make and validate the xenocara release.
- Make the third party packages.
The following sections describe each of the required steps in detail.
Commands to be run as a user with write permissions on the source and ports trees (/usr/src and /usr/ports respectively) are preceded by a dollar sign (‘$’). Commands that must be run as the superuser are preceded by a hash mark (‘#’).
1. Update sources
A release
should always start from a known
set of
coherent
sources. The easiest way to ensure that the sources are complete and
coherent is to check them out using the CVS tag the
OpenBSD developers add to the repository prior to
making a release. There are two tags, one which identifies the release as it
exists on the CD-ROM and another which identifies the
stable branch. The stable branch,
starting with OpenBSD 2.7, contains the patches
described in
http://www.openbsd.org/errata.html.
The tags are of the form:
- OPENBSD_x_y_BASE
- This tag marks the source as it exists on the release CD-ROM where x is the major release number and y is the minor release number.
- OPENBSD_x_y
- This tag is a moving target. It marks the sources that belong to the stable branch. This branch only contains errata, no new features.
To update your sources to the versions identified by one of the above tags use the commands:
$ cd /usr/src && cvs up -r TAG -Pd $ cd XSRCDIR && cvs up -r TAG -Pd $ cd PORTSPATH && cvs up -r TAG -Pd
Replace XSRCDIR with the path to your X Window System sources. Replace PORTSPATH with the path to your ports tree sources, typically /usr/ports. The above commands assume an existing source tree.
See http://www.openbsd.org/anoncvs.html for instructions on fetching the sources for the first time.
Warning: CVS tags are ‘sticky’. See cvs(1) for more information.
2. Build and install a new kernel
For safety, you should always build and install a new kernel before building the programs that will use the kernel. This ensures that any new system calls, for example, will be present when needed. To build a kernel the steps are:
Change the current working directory.
${ARCH} is the architecture of your machine, e.g.
i386
.
$ cd
/usr/src/sys/arch/${ARCH}/conf
Edit the kernel configuration file.
${NAME} is your kernel configuration file. You should
not edit
GENERIC
; create your own kernel configuration if you
need to make modifications. If using GENERIC
you can
skip this step. And yes, you may use
vi(1),
mg(1),
or any other editor you choose.
$ vi ${NAME}
Build the kernel compilation directory and compile the kernel:
$ config ${NAME} $ cd ../compile/${NAME} $ make clean && make
(In this instance make clean
is your
friend.)
Replace the old kernel and reboot. The current kernel is copied to /obsd and the new kernel to /bsd.
$ su # make install # shutdown -r now
If the system does not come up you can boot using /obsd.
3. Build a new system
Now that you are running your new kernel you can build a new system. It's safer (but slower) to remove your object directories and re-create them before the build. The steps are:
Move all your existing object files out of the way and then remove them in the background:
$ cd /usr/obj && mkdir -p .old && sudo mv * .old && \ sudo rm -rf .old &
Re-build your obj directories:
$ cd /usr/src && make
obj
Create directories that might be missing:
$ cd /usr/src/etc && env
DESTDIR=/ sudo make distrib-dirs
Begin the build:
$ cd /usr/src && make
SUDO=sudo build
Update /etc, /var, and /dev/MAKEDEV, either by hand or using sysmerge(8).
At this point your system is up-to-date and running the code that you are going to make into a release.
4. Make and validate the system release
The system release consists of at least one generic kernel, some installation media, the release ‘tarballs’, installation instructions, and checksum files.
The release process requires two work areas. They are:
- DESTDIR
- This is the name of a directory which will be the root of a complete OpenBSD installation, thus it must be on a disk partition large enough to store the entire operating system (less the X Window System and any third party ‘packages’). The directory can be removed once the release is created. In any case the release process ensures the directory is empty before starting.
- RELEASEDIR
- This is the name of a directory where the release output files are stored. The following process will create the directory if necessary.
- Warning: DESTDIR and RELEASEDIR must not refer to any directory with /mnt in its path, as /mnt is used in the release generation process. Additionally the first vnd(4) device, vnd0, is also used and must not be configured.
The release process is:
Ensure ${DESTDIR} exists as an empty directory and ${RELEASEDIR} exists. ${RELEASEDIR} need not be empty. You must be root to create a release:
$ su # export DESTDIR=your-destdir; export RELEASEDIR=your-releasedir # test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \ rm -rf ${DESTDIR}- & # mkdir -p ${DESTDIR} ${RELEASEDIR}
Make the release and check that the contents of ${DESTDIR} pretty much match the contents of the release ‘tarballs’:
# cd /usr/src/etc && make release # cd /usr/src/distrib/sets && sh checkflist # unset RELEASEDIR DESTDIR
At this point you have most of an OpenBSD release. The only thing missing is the X Window System (which is covered in the next section).
5. Build and install xenocara
Xenocara is based on the X.Org modular build system. Xenocara sources are supposed to be in XSRCDIR which defaults to /usr/xenocara. This variable should be set in mk.conf(5) if a non-default value is used. The /usr/src tree is also needed while building xenocara. The following steps will build and install everything for the first time.
$ su # cd XSRCDIR # make bootstrap # make obj # make build
The X Window System is created and installed in /usr/X11R6.
6. Make and validate the xenocara release
xenocara uses DESTDIR and RELEASEDIR as described above. While they may be set to the values used to build the rest of the system, be aware that the existing contents of DESTDIR will be removed as part of the xenocara build (this is necessary for release checklist processing).
The steps to build the release are (assuming you are still root, and still in XSRCDIR):
# export DESTDIR=your-destdir; export RELEASEDIR=your-releasedir # test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \ rm -rf ${DESTDIR}- & # mkdir -p ${DESTDIR} ${RELEASEDIR} # make release # unset RELEASEDIR DESTDIR
At this point you have both OpenBSD system and X Window System ‘tarballs’ in your release directory.
7. Make the third party packages
The ‘ports’ subsystem of contributed applications is capable of producing ‘packages’ for installation, either individually or in bulk. This is described in ports(7).
SEE ALSO
HISTORY
This document first appeared in OpenBSD 2.8.