Overview
Earlier this month, I converted my primary Opteron server running 10+ zones on Solaris 10 over to OpenSolaris 2009.06. With a more modern environment available on my best hardware, I decided to create a zone specifically for hosting builds for Source Juicer packages and OS/Net.
Since the first release of Project Indiana last year, a number of people have been working toward making ON development possible. In April, Liane Praza made the `osnet' package available in the /dev repository along with updated instructions on the Project Indiana project site. With the release of a number of missing packages to the /extras repository earlier this year and a little elbow grease it is now possible to build ON from within Project Indiana with no need to install auxiliary packages from SXCE.
Unfortunately the `osnet' package is only available from the /dev repository which leaves those following /release out in the cold. Also, `osnet' is a one-size-fits-all solution to dealing with ON dependencies; everything is installed unconditionally (even some of the heavier bits, such as both versions of Apache, and PostgreSQL).
Since I spend about 99.9% of my time hacking in uts, I wanted a lighter-weight solution.
There are a number of caveats to using a build environment such as this; some obvious, some not:
- Be aware that you can build any version of ON which supports the dependencies available in /release.
- If you plan to do more than just build kernel modules, built modules should match the installed kernel version.
- An snv_108 (or greater) host is required to avoid Bug 6798733; It's worth mentioning that Edward Pilatowicz has posted a workaround for builds prior to snv_108.
In my case, I was creating up a build environment within a zone. If you wish to do the same, you must ensure that the SUNWcar and SUNWkvm packages are installed:
% pfexec pkg install SUNWcar SUNWkvmThe following packages are required at a minimum to build uts:
% pfexec pkg install SUNWperl584usr SUNWperl-xml-parser SUNWhea SUNWsprot \If you happen to be outside of the Sun firewall, you will also want to install Mercurial and wget. For the remainder of this post, it is assumed that this is the case:
SUNWbtool SUNWtss SUNWgcc
% pfexec pkg install SUNWmercurial SUNWwgetUnfortunately SUNWonbld is only made available as an IPS package in the /dev repository. If you prefer to use a local install for day-to-day development, you will need to install SVR4 packaging support and download the SUNWonbld package from the OpenSolaris Download Center. If you only intend to use nightly(1), then this step may be skipped safely.
% pfexec pkg install SUNWpkgcmdsUpdate: It appears that SUNWonbld is now available as an IPS package in the /release repository.
% cd /var/tmp; wget http://dlc.sun.com/osol/on/downloads/current/SUNWonbld.i386.tar.bz2
% bzcat SUNWonbld.i386.tar.bz2 | tar xf -
% pfexec pkgadd -d onbld SUNWonbld
You will need to download and install the Sun Studio 12 tarball provided by the Tools Community. Also, you must ensure that /opt/SUNWspro points to your Sun Studio install. Please, please do not attempt to build uts with Sun Studio Express - you will not be pleasantly surprised.
% mkdir -p /opt/SunStudio12; cd /opt/SunStudio12At this point you should update your PATH; this is absolutely critical. If your PATH is not setup correctly, uts may fail to build. If you did not install SUNWonbld locally (see above), then you may drop the first two paths below:
% gzcat sunstudio12-ii-20081010-sol-x86.tar.gz | tar xf -
% ln -sf /opt/SunStudio12 /opt/SUNWspro
% PATH=/opt/onbld/bin:/opt/onbld/bin/`uname -p`:\At this point, you are ready to clone the onnv-gate:
/opt/SUNWspro/bin:/usr/bin:/usr/sbin:/usr/ccs/bin; export PATH
% hg clone ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gateChange your working directory to the freshly cloned gate, then download and unpack the closed binaries from the OpenSolaris Download Center:
% wget http://dlc.sun.com/osol/on/downloads/current/on-closed-bins.i386.tar.bz2You will also need to copy and edit opensolaris.sh. Pay especial attention to GATE, CODEMGR_WS, and STAFFER. Don't forget to remove 't' from NIGHTLY_OPTIONS if you have SUNWonbld installed locally. I typically alter maxjobs() to a more reasonable value - the default tends to be a little aggressive on a shared system.
% bzcat on-closed-bins.i386.tar.bz2 | tar xf -
% cd onnv-gate; cp usr/src/tools/env/opensolaris.sh .Finally, issue bldenv(1) to setup your build environment. If you downloaded the debug closed bins, make sure that you pass -d for a debug build:
% vi opensolaris.sh
% bldenv -d opensolaris.shBuilding the Kernel
At this point, building the kernel is pretty straightforward. In order to keep dmake from complaining on each invocation, you will want to set the DMAKE_MODE environment variable if you have not already done so in your .dmakerc:
% DMAKE_MODE=parallel; export DMAKE_MODEIf the SUNWonbld package was not installed earlier (see above), or you prefer to use the tools provided in the gate, you will need to install them first:
% cd $SRC/tools; dmake installOnce the build tools are available, you will need to issue a `dmake setup' from the top level source directory:
% cd $SRC; dmake setupAt this point you are free to build uts:
% cd $SRC/uts; dmake allAs always, YMMV.

After an update to 111b, I found osnet and onbld in the repository. You should check that.
ReplyDeleteIt appears that onbld is available in /release, however osnet is not. Out of curiosity, what does 'pkg authority opensolaris.org' yield?
ReplyDeleteluis@meg:~$ pkg publisher
ReplyDeletePUBLISHER TYPE STATUS URI
opensolaris.org (preferred) origin online http://pkg.opensolaris.org/release/
extra origin online https://pkg.sun.com/opensolaris/extra/
You know what is odd, when I run in the console 'pkg search osnet' no result is thrown. However, when I do the same search in the pkg GUI, it find the package. Weird...
Something that I did not understand is how to boot the new kernel in a separate zone.
Interesting. I almost never use the Package Manager.
ReplyDeleteIf you are using a zone to build, then you will likely be unable to do much of anything interesting on the build host. This type of setup requires a target machine for testing the kernel.
These instructions should work for non-zoned build hosts.
Depending on what area of uts you work in, its generally a good idea to keep your build and target hosts separate.
I wanted to work in the Virtual Memory sub-system. My problem was that, after compiling, the kernel was unable to boot completely. For some reason, the zpools were not mounted. I suspect of the network daemons. When the network does not work, for some reason, the zpools are not mounted properly.
ReplyDeleteThat is why I was wondering if it was better to use a zone to do my development. Besides, I don't have to reboot the machine for every test.