.------o-----------o----X 5.9 Stable
| . .
| . .------o---------o----X 6.0 Stable
| . | . .
| . | . .----o----------o--> 6.1 Stable
| . | . | . .
| . | . | . .-----o--> 6.2 Stable
| . | . | . | .
| . | . | . | .
-->5.9Rel----->6.0Rel----->6.1Rel----->6.2Rel----> Current
Time --->
The name -stable refers to API-stability: the way programs talk to the OS is not changed in this branch. In contrast, in -current, the APIs are changing and evolving.
New users should be running either -stable or -release. That being said, many people do run -current on production systems to help catch bugs and test new features.
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.
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 following -current and using snapshots for any configuration changes or extra steps necessary to build -current from source.
Make sure you have the closest available binaries installed. This is either OpenBSD x.y-release if you want to build OpenBSD x.y-stable, or the latest snapshot if you wish to build -current.
This change takes effect with exampleuser's next login.# user mod -G wsrc exampleuser
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
Once you have the tree checked out, you can update it at a later time with:$ cd /usr $ cvs -qd anoncvs@anoncvs.example.org:/cvs checkout -rOPENBSD_6_2 -P src
Replace 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/src $ cvs -q up -Pd -rOPENBSD_6_2
Update the tree with:$ cd /usr $ cvs -qd anoncvs@anoncvs.example.org:/cvs checkout -P src
Replace src with the module you want, such as xenocara or ports.$ cd /usr/src $ cvs -q up -Pd -A
If you are building -current, review changes and special build instructions listed on current.html.
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.
If you'd like to cryptographically sign the sets you created, the signify(1) man page has details on how to do so.# ls -nT > index.txt
Create a filesystem on /dest with the noperm mount(8) option set. The corresponding fstab(5) line might look like this:
The root directory of this filesystem must be owned by build with permissions 700:c73d2198f83ef845.m /dest ffs rw,nosuid,noperm 1 2
Create the DESTDIR directories for base and xenocara:# chown build /dest # chmod 700 /dest
# mkdir /dest/{,x}base
Create the prototype DESTDIR directories:swap /dest mfs rw,nosuid,noperm,-P/var/dest,-s1.5G,noauto 0 0
# mkdir -p /var/dest/{,x}base
# chown -R build /var/dest
# chmod -R 700 /var/dest
# 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:
$ cd /usr/src $ find . -type l -name obj | xargs rm $ 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.
In most program or library source directories, you can create a ./tags file by running:
When building and installing libc, a /var/db/libc.tags file is also created.$ make tags
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/.
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.
However, this will only correct your problem for one time. If you reboot, you will have to repeat this procedure. So, this is only a temporary fix, and you should correct the problem using config(8).
To boot into the User Kernel Config, or UKC, use the -c option at boot-time.
Doing this will bring up a UKC prompt. Type help for a list of available commands.boot> boot hd0a:/bsd -c
For safety's sake, use the -o option which writes the changes out to the file specified. For example: config -e -o bsd.new /bsd will write the changes to bsd.new. Kernel modification examples are given in the config(8) man page.
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
in your repository and generate your diff like this:$ git config diff.noprefix true
$ git diff --relative .