|
|||||||||||||||||||||||||
|
|
4. Building a Kernel and RamdiskBuilding your own kernel and ramdisk is necessary if you want to
Otherwise, feel free to skip this section. 4.1. Getting SSI SourceSSI source code is available as official release tarballs and through CVS. The CVS repository contains the latest, bleeding-edge code. It can be less stable than the official release, but it has features and bugfixes that the release does not have. 4.1.1. Official ReleaseThe latest SSI release can be found at the top of this release list. At the time of this writing, the latest release is 0.6.5. Download the latest release. Extract it.
Determine the corresponding kernel version number from the release name. It appears before the SSI version number. For the 0.6.5 release, the corresponding kernel version is 2.4.16. 4.1.2. CVS CheckoutFollow these instructions to do a CVS checkout of the latest SSI code. The modulename is ssic-linux. You also need to check out the latest CI code. Follow these instructions to do that. The modulename is ci-linux. To do a developer checkout, you must be a CI or SSI developer. If you are interested in becoming a developer, read Section 8.3 and Section 8.4. Determine the corresponding kernel version with
In this case, the corresponding kernel version is 2.4.16. If you're paranoid, you might want to make sure the corresponding kernel version for CI is the same.
They will only differ when I'm merging them up to a new kernel version. There is a window between checking in the new CI code and the new SSI code. I'll do my best to minimize that window. If you happen to see it, wait a few hours, then update your sandboxes.
4.2. Getting the Base KernelDownload the appropriate kernel source. Get the version you determined in Section 4.1. Kernel source can be found on this U.S. server or any one of these mirrors around the world. Extract the source. This will take a little time.
or
4.3. Applying SSI Kernel CodeFollow the appropriate instructions, based on whether you downloaded an official SSI release or did a CVS checkout. 4.3.1. Official ReleaseApply the patch in the SSI source tree.
4.3.2. CVS CheckoutApply the UML patch from either the CI or SSI sandbox. It will fail on patching Makefile. Don't worry about this.
Copy CI and SSI code into place.
Apply the GFS patch from the SSI sandbox.
Apply any other patch from ssic-linux/3rd-party at your discretion. They haven't been tested much or at all in the UML environment. The KDB patch is rather useless in this environment. 4.4. Building the KernelConfigure the kernel with the provided configuration file. The following commands assume you are still in the kernel source directory.
Build the kernel image and modules.
4.5. Adding GFS Support to the HostTo install the kernel you must be able to loopback mount the GFS root image. You need to do a few things to the host system to make that possible. Download any version of OpenGFS after 0.0.92, or check out the latest source from CVS. Apply the appropriate kernel patches from the kernel_patches directory to your kernel source tree. Make sure you enable the /dev filesystem, but do not have it automatically mount at boot. (When you configure the kernel select 'File systems -> /dev filesystem support' and unselect 'File systems -> /dev filesystem support -> Automatically mount at boot'.) Build the kernel as usual, install it, rewrite your boot block and reboot. Configure, build and install the GFS modules and utilities.
Configure two aliases for one of the host's network devices. The first alias should be 192.168.50.1, and the other should be 192.168.50.101. Both should have a netmask of 255.255.255.0.
cat the contents of /proc/partitions. Select two device names that you're not using for anything else, and make two loopback devices with their names. For example:
Finally, load the necessary GFS modules and start the lock server daemon.
Your host system now has GFS support. 4.6. Installing the KernelLoopback mount the shared root.
Install the modules into the root image.
4.7. Building GFS for UMLYou have to repeat some of the steps you did in Section 4.5. Extract another copy of the OpenGFS source. Call it opengfs-uml. Add the following line to make/modules.mk.in.
Configure, build and install the GFS modules and utilities for UML.
4.8. Building the RamdiskChange root into the loopback mounted root image, and use the --uml argument to cluster_mkinitrd to build a ramdisk.
Move the new ramdisk out of the root image, and assign ownership to the appropriate user. Wrap things up.
4.9. Booting the ClusterPass the new kernel and ramdisk images into ssi-start with the appropriate pathnames for KERNEL and INITRD in ~/.ssiuml/ssiuml.conf. An example for KERNEL would be ~/linux/linux. An example for INITRD would be ~/initrd-ssi.img. Stop the currently running cluster and start again.
You should see a three-node cluster booting with your new kernel. Feel free to take it through the exercises in Section 3 to make sure it's working correctly. | ||||||||||||||||||||||||
|
|||||||||||||||||||||||||