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 --->
Further thoughts on the three flavors are here.
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.
On fast platforms, several snapshots may be released in one day. On slower platforms, it may take a week or more to build a snapshot. Providing tags or markers in the source tree for each snapshot would be quite impractical.
|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.
An introduction to cvs(1) and detailed instructions for fetching the source trees are on the Anonymous CVS page. If you are new to using cvs(1), you may also want to read the CVS tips below.
Since they're not part of the base install, you must create the directories and set their permissions manually to make use of the wsrc group:# 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 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 -qd firstname.lastname@example.org:/cvs 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 resultant 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.
# 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) manpage.
Read the config(8) and the options(4) manpages 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
In fact, as our hope is to continually improve OpenBSD, the goal is that -current should be more reliable, more secure and, of course, have greater features than -stable. Put bluntly, the "best" version of OpenBSD is -current.
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. However, if you don't know how to properly describe, diagnose and deal with a problem, don't tell yourself (or anyone else) that you're "helping the project" by running -current. "It didn't work!" is not a useful bug report. "The recent changes to the pciide driver broke compatibility with my Slugchip-based IDE interface, dmesg of working and broken systems follow..." might be a useful report.
There are times when "normal" users may wish to live on the cutting edge and run -current. The most common reason is that the user has a device which is not supported by -release (and thus, not -stable), or wishes to use a new feature of -current. In this case, the choice may be either -current or not using the device, and -current may be the better option. However, one should not expect hand-holding from the developers.
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 email@example.com:/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