When very important fixes are made to -current, they are backported into the two supported -stable branches.
Every six months, -current is tagged and becomes the next -release: a frozen point in the history of the source tree.
In the above illustration, the vertical dotted lines denote bug fixes being incorporated into the -stable branches.,------o-----------o----X 5.6 Stable | . . | . ,------o---------o----X 5.7 Stable | . | . . | . | . ,----o----------o--> 5.8 Stable | . | . | . . | . | . | . ,-----o--> 5.9 Stable | . | . | . | . | . | . | . | . -->5.6Rel----->5.7Rel----->5.8Rel----->5.9Rel----> Current Time --->
It is worth pointing out that the name -stable is not intended to imply that -current is unreliable or less robust in production. Rather, the APIs (how the programs talk to the OS) and features of -current are changing and evolving, whereas the operation and APIs of -stable are the same as the release it is based on.
Most users should be running either -stable or -release. That being said, many people do run -current on production systems, and it is important that people do so to identify 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 in a snapshot, make sure it is reported.
If you desire to run -current, a recent snapshot is usually all you need. Upgrading to a snapshot is the starting point before building -current from source.
Details can be found on the following -current page.
|You are at||Goal||Binary upgrade to||then ...|
|Old -release||New release||Newest release||Done!|
|-release||-stable||Newest release||Fetch & build -stable|
|Old -stable||-stable||Newest release||Fetch & build -stable|
|-release||-current||Latest snapshot||(optional) Fetch & build -current|
|Old -current||-current||Latest snapshot||(optional) Fetch & build -current|
It is recommended that you install the binary sets by using the (U)pgrade option of the install media. If that is not possible, you can also unpack the binary sets as described in the upgrade instructions of the release.
First, you must cvs checkout the source tree. After that, you maintain the tree by running cvs update to pull updated files to your local tree.
If you want to fetch xenocara or ports as this user, you must create the directories and set their permissions manually.# user mod -G wsrc exampleuser
# 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 firstname.lastname@example.org:/cvs checkout -rOPENBSD_5_9 -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 -rOPENBSD_5_9 -Pd
Update the tree with:$ cd /usr $ cvs -qd email@example.com:/cvs checkout -P src
Replace src with the module you want, such as xenocara or ports.$ cd /usr/src $ cvs -q up -Pd
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 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
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.
...than to remove the contents of the directory with rm.# umount /usr/obj # newfs YourObjPartition # mount /usr/obj
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 /usr/src/sys/arch/$(machine)/conf $ cp GENERIC CUSTOM $ vi CUSTOM # make your changes $ config CUSTOM $ cd ../compile/CUSTOM $ make
The -P option removes directories that are empty. Sometimes the names of old directories are currently used as file names.
The -d option on the update command creates new directories that may have been added to the tree since the initial checkout.
cvs -q -d firstname.lastname@example.org:/cvs diff -uNp update -Pd checkout -P rdiff -u
Note also that the CVSROOT environment variable is only used if cvs(1) would throw an error without it.
To see the changes between 5.9 and -current, use:$ cd /usr/src/etc $ cvs diff -u -rOPENBSD_5_8 -rOPENBSD_5_9
$ cd /usr/src/etc $ cvs diff -u -rOPENBSD_5_9 -rHEAD