New users should be running either -stable or a release. That being said, many people do run -current on production systems to help catch bugs and test new features.
A recent snapshot is usually all you need to run -current. If you wish to build it from source, starting from the latest snapshot is required. Check the following -current and using snapshots page for any configuration changes or extra steps needed to build from source.
It is possible that you may uncover bugs in snapshots. This is one of the reasons why they are built and distributed. If you find a bug, make sure it is reported.
Make sure you have the closest available binaries installed. This is either OpenBSD x.y if you want to build OpenBSD x.y-stable, or the latest snapshot if you wish to build -current.
cvs checkout the source tree.
After that, you maintain the tree by running cvs update to pull
updated files to your local tree.
You can also maintain a local CVS repository using the reposync
program, available as a package.
Setting up a mirror of the repository is also explained on the
anonymous CVS page.
/usr/src directory (where your source will typically go) is
writable by the wsrc group by default, so add users that need
to use cvs(1) to that group.
# user mod -G wsrc exampleuserThis change takes effect with exampleuser's next login.
If you want to fetch xenocara or ports as this user, you must create the directories and set their permissions manually.
# cd /usr # mkdir -p xenocara ports # chgrp wsrc xenocara ports # chmod 775 xenocara ports
src tree, specify the branch you want with
the -r flag:
$ cd /usr $ cvs -qd [email protected]:/cvs checkout -rOPENBSD_7_3 -P srcOnce you have the tree checked out, you can update it at a later time with:
$ cd /usr/src $ cvs -q up -Pd -rOPENBSD_7_3Replace
src with xenocara or ports
as appropriate.
As all parts of OpenBSD must be kept in sync, all the trees you use should be
checked out and updated at the same time.
$ cd /usr $ cvs -qd [email protected]:/cvs checkout -P srcUpdate the tree with:
$ cd /usr/src $ cvs -q up -Pd -AReplace
src with the module you want, such as xenocara
or ports.
If you are building -current, review changes and special build instructions listed on this page.
Follow the detailed instructions in steps 2 and 3 of release(8).
The instructions on making a release are in
release(8).
The release process uses the binaries created in the /usr/obj
directory in the building process above.
Note: if you wish to distribute the resulting file sets by HTTP(s) for use by
the upgrade or install scripts, you will need to add an index.txt
file that contains the list of all the files in your newly created release.
# ls -nT > index.txtIf you'd like to cryptographically sign the sets you created, the signify(1) man page has details on how to do so.
noperm partition.
This allows the build infrastructure to use the unprivileged build
user for much of the process.
Create a filesystem on /dest with the noperm
mount(8) option set.
The corresponding fstab(5)
line might look like this:
c73d2198f83ef845.m /dest ffs rw,nosuid,noperm 1 2The root directory of this filesystem must be owned by
build with
permissions 700:
# chown build /dest # chmod 700 /destCreate the
DESTDIR directories for base and xenocara:
# mkdir /dest/{,x}base
Your RELEASEDIR does not need to be on a noperm
filesystem.
Make sure that it is owned by build and has at least permissions
u=rwx.
/etc/fstab:
swap /dest mfs rw,nosuid,noperm,-P/var/dest,-s1.5G,noauto 0 0Create the prototype
DESTDIR directories:
# mkdir -p /var/dest/{,x}base
# chown -R build /var/dest
# chmod -R 700 /var/dest
Now you can mount /dest before making a release:
# mount /dest
To simplify life for OpenBSD users, a meta-build called Xenocara was developed. This system converts X back into one big tree to be built in one process. As an added bonus, this build process is much more similar to the build process used by the rest of OpenBSD than the previous versions were.
The official instructions for building X exist in the
xenocara/README file and in step 5 of
release(8).
Most problems are usually one of the following:
make obj before make buildmake build before doing a make obj,
you will end up with the object files scattered in your /usr/src
directory.
This is a bad thing.
If you wish to try to avoid re-fetching your entire src tree again, you
can try the following to clean out obj files:
$ cd /usr/src $ find . -type l -name obj -delete $ make cleandir $ rm -rf /usr/obj/* $ make obj
You will probably find it best to repair or replace the components that are causing trouble, as problems may show themselves in other ways in the future.
For much more information, see the Sig11 FAQ.
wobj groupwobj
group.
This will allow you to write to /usr/obj.
In most program or library source directories, you can create a
./tags
file by running:
$ make tagsWhen building and installing
libc, a
/var/db/libc.tags file is also created.
By default, kernel tags for each architecture are located in
/sys/arch/$(machine)/.
These files can be created with make tags from
/sys/kern.
You may want to run make links as root to place a symlink to
your architecture's kernel tags file in each directory and in
/var/db/.
SKIPDIR option of
mk.conf(5).
When the developers bring up support for a new platform, one of the first big tests is a native-build. Building the system from source puts considerable load on the OS and machine, and does a very good job of testing how well the system really works. For this reason, OpenBSD does all the build process on the platform the build is being used for.
To boot into the User Kernel Config, or UKC, use the -c
option at startup time:
Using drive 0, partition 3. Loading...... probing: pc0 com0 com1 mem[638K 1918M a20=on] disk: hd0+ hd1+ >> OpenBSD/amd64 BOOT 3.33 boot> boot hd0a:/bsd -cDoing this will bring up a UKC prompt. Type
help for a list of available commands.
Using boot_config(8) only provides a temporary change, meaning the procedure would have to be repeated on every reboot. The next section explains how to make the changes permanent.
-e flag allows you to enter the UKC on a running system.
Any changes made will then take effect on the next reboot.
The -u flag tests to see if any changes were made to the running
kernel during boot, meaning you used boot -c to enter the UKC
while booting the system.
To avoid the risk of overwriting the working kernel with a broken one,
consider using the -o flag to write the changes out to a
separate kernel file for testing:
# config -e -o /bsd.new /bsdThis will write your changes to the
/bsd.new file.
Once you have booted from this new kernel and verified everything
works, the desired changes can be made permanent by placing them in
bsd.re-config(5).
Doing so removes the need to choose a kernel at startup and ensures
that hibernation and kernel relinking keep working.
Kernel modification examples are given in the config(8) man page.
GENERIC and GENERIC.MP kernels are supported
by the OpenBSD team.
The GENERIC kernel configuration is the combination of the options
in /sys/arch/$(machine)/conf/GENERIC
and /sys/conf/GENERIC.
Reporting a problem on a customized kernel will almost always result in
you being told to try to reproduce the problem with a GENERIC
kernel.
Read the config(8) and the options(4) man pages first. The following steps are part of compiling a custom kernel:
$ cd /sys/arch/$(machine)/conf $ cp GENERIC CUSTOM $ vi CUSTOM # make your changes $ config CUSTOM $ cd ../compile/CUSTOM $ make
cvs diff -uNp to generate the diff.
$ git config diff.noprefix truein your repository and generate your diff like this:
$ git diff --relative .