OpenSSI Logo SourceForge Logo

 home page
 sourceforge page
 mailing lists
 feature list
 Bruce's corner
 related links
 1.2 stable
 1.9 development
 1.2 stable
 1.9 development
work items
 task list
 bug database
 feature requests
 process mgmt hooks
  hide sidebar

Only use this document if you are interested in building OpenSSI RPMs 
for Fedora Core or SuSE. If you want to build packages for Debian, please 
see openssi/docs/debian/devel/INSTALL.cvs in the OpenSSI CVS repository.

This document is a supplement to INSTALL. It describes how to build most 
RPMs required by section 2 of INSTALL. It also describes how to build
an individual RPM and how to generate a complete kernel source tree.
All commands for building RPMs should be run as root.

You should install the mknbi RPM from the latest binary release. It is not 
built as part of these instructions.

First be sure you install the glib-devel package from your distribution CDs:
	# rpm -Uhv glib-devel-*
	# rpm -Uhv dietlibc-*

Building the devfsd RPM requires that /usr/src/linux-2.6 contains a kernel 
tree. If it does not exist, make it a symlink:
	# ln -s linux-<kernel_version> /usr/src/linux-2.6

If /usr/src/linux-<kernel_version> also does not exist, then install the 
kernel-source RPM from your distro's installation CDs, or download the 
kernel-ssi-source RPM from

Now checkout the sandboxes you need (if you are reading this document,
you probably checked out an openssi sandbox already). Do _not_ do these 
checkouts in /usr/src!

Replace <branch_name> with OPENSSI-FC if you are building for Fedora Core, 
or OPENSSI-SU if you are building for SuSE:
	# cvs -d $CIREP login
	<press Enter when prompted for password>
	# cvs -z3 -d $CIREP co -r <branch_name> ci

	# cvs -d $SSIREP login
	<press Enter when prompted for password>
	# cvs -z3 -d $SSIREP co -r <branch_name> openssi
	# cvs -z3 -d $SSIREP co -r <branch_name> srpms

The procedure is a bit different if you are an official OpenSSI developer.
In this case, replace <user_name> with your SourceForge user name:
	# CIREP=:ext:<user_name>
	# cvs -z3 -d $CIREP co -r <branch_name> ci

	# SSIREP=:ext:<user_name>
	# cvs -z3 -d $SSIREP co -r <branch_name> openssi
	# cvs -z3 -d $SSIREP co -r <branch_name> srpms

Install the base source RPMs:
	# rpm -ihv srpms/*.rpm

Extract the base kernel source:
	# tar jxf srpms/linux-2.6.10.tar.bz2

Your directory should contain the following:
	# ls
	ci  linux  openssi  srpms

One last thing you should do is move aside any other RPMs you might have
built in the past, since they could be easily confused with the plethora
of OpenSSI RPMs you are about to build. These old RPMs (if any) can be
found in the /usr/src/redhat/RPMS/* directories.

Now you are ready to actually build RPMs.

Building all RPMs

First build a cluster-tools RPM:
	# cd ci
	# make rpms

Install the freshly built cluster-tools RPM. It is needed to build some
of the other RPMs:
	# RPMDIR=/usr/src/redhat/RPMS
	# rpm -Uhv $RPMDIR/i386/cluster-tools-<latest version>.i386.rpm

If you already have a version of cluster-tools installed, it's possible 
that the new package will conflict with it. This would happen if the 
package you built has the same version/release number as what is already 
installed. One solution would be to increment the SSI release number in
the cluster-tools specfile before building the RPM, but how to do this is 
beyond the scope of this document. An easier solution is to use the --force 
option with the `rpm -Uhv ...' command above.

Next build the OpenSSI RPMs:
	# cd ../openssi
	# make rpms

The kernel build in particular should take awhile. Once it is done, you will 
find the RPMs you need under /usr/src/redhat/RPMS. The various utilities are
in the i386 subdirectory. The new kernel RPM is in the i686 subdirectory.

You can delete the *-debuginfo-* RPMs. You can also delete e2fsprogs-devel, 
losetup and ntsysv, since no code is modified in these RPMs.

The rest of this section tells you how to install these RPMs as if you
were installing an official OpenSSI release. The instructions assume that
you do not already have OpenSSI installed.

Create some subdirectories in your openssi sandbox:
	# mkdir -p RPMS/base
	# mkdir -p RPMS/ssi

Move your new kernel RPM from /usr/src/redhat/RPMS/i686 into openssi/RPMS. 
Move the rest of the OpenSSI RPMs from /usr/src/redhat/RPMS/i386 into
openssi/RPMS/ssi. The openssi/RPMS/base does not need anything in it.

Continue following the instructions in section 2 of INSTALL, starting with
the ./install script.

Building Individual RPMs

You can also build individual RPMs. For example:
	# cd ci; make cluster-tools.rpm
		-- or --
	# cd openssi; make kernel.rpm
		-- or --
	# cd openssi; make openssi-tools.rpm
		-- or --
	# cd openssi; make sysvinit.rpm
		-- etc. --

The only RPMs you can build in the ci directory is cluster-tools and the
CI kernel (not needed for OpenSSI). To find out what RPMs can be built in 
the openssi directory, look at the the rpms and utilrpms rules at the bottom 
of openssi/Makefile.

Generating a kernel source tree

You do not need to be the root user for these instructions. 

Generate a linux-ssi directory with the complete kernel source with:
	$ cd openssi
	$ make kern
	   -- or --
	$ make fullkern

The difference between the two rules is that 'make kern' only applies
the OpenSSI changes to the base Linux kernel source, whereas
'make fullkern' also applies a set of third-party patches, including
SGI's kernel debugger, Linux Virtual Server, modifications needed for
Lustre, etc. At present, some of these patches are required for building
an OpenSSI kernel, so the 'make kern' rule does not generate a buildable 
source tree. Only 'make fullkern' does this.

To browse the source, it is useful to have a tool such as cscope:

It requires an list of all files to index, which the following command
can generate for you:
	$ cd linux-ssi
	$ find \
	    ! -path './arch/i386*' -path './arch/*' -prune -o \
	    ! -path './include/asm-i386*' -path './include/asm*' -prune -o \
	    \( -name '*.[chxsS]' -o -name '*.svc' \) -print \

Finally, index everything with:
	$ cscope -k

Now you can use cscope to easily find definitions for functions, structures, 
etc. Also, the vim command has integrated support for cscope, which lets
you use Ctrl-] to find the definition for a symbol and Ctrl-t to pop back
to where you came from.

Building a kernel source tree

To build an OpenSSI kernel, you should start with one of the 
pre-defined kernel config files in openssi/kernel.configs. The 
kernel-ssi-i686-smp.config file is derived from Fedora Core 3's 
kernel-2.6.10-i686-smp.config file. It is what is used to generate the
kernel RPM for releases. You can also use development.i686, which is a 
stripped-down config file used by many developers because it builds much 
more quickly.

If you want to customize one of these config files, you must at a minimum
say Y to BLK_DEV_INITRD (initial ramdisk support) and say N to SECURITY, 
DEVPTS_FS_XATTR, and DEVPTS_FS_SECURITY to enable SSI clustering. You must 
also set the default RAM disk size to 9000. Also, you should statically 
compile (Y, not M) IPVS and Unix domain sockets. There might be other kernel 
features that are necessary, as well. If you determine something else that 
is required, please send an e-mail to

Building the kernel is the same as usual. First configure your build:
	$ cd linux-ssi
	$ cp ../openssi/kernel.configs/kernel- .config
	$ make oldconfig

Then you're ready to actually do the build:
	$ make

Alternatively, you can use make's -j option to take advantage of an SMP 
system (or an OpenSSI cluster):
	$ make -j <num_cpus>

Installation is similar to the usual procedure, although not identical. 
You must use the --cfs option to mkinitrd, or your kernel will not be
able to join the cluster.

Do the following as root (x is a kernel revision number that changes with 
each release):
	# make modules_install
	# cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.10_ssi_x
	# mkinitrd --cfs /boot/initrd-2.6.10_ssi_x.img \

Add a stanza to /etc/grub.conf for your new kernel and initrd, and set 
it as the default. In addition, run the ssi-ksync command to update the 
/tftpboot directory with a copy of the new default kernel and initrd, so 
that network booting nodes can find it. The ssi-ksync command also 
distributes copies of all kernels and initrds in /etc/grub.conf to nodes 
with local boot partitions. All nodes with local boot partitions must be 
up at the time to receive the updates. If such a node is not up and it 
misses the update, it would be safest to network boot it next time, then run 
ssi-ksync again after it has joined the cluster.

Finally, reboot the cluster. If all goes well, you should be running your 
custom-built kernel.

This page last updated on Thu Dec 15 17:17:44 2005 GMT
privacy and legal statement