KUSP Testbed Setup

A KUSP Testbed machine is a Linux box like any other, but there are some basic procedures to following in setting it up for convenient use.

File Systems

We use NFS access to each person’s build area on yggdrasil to make many kinds of testing more convenient, although it is in some ways less realistic as it involves NFS access to commands, etc. We use the /debugfs for, well, debugging.

Edit /etc/fstab, which you will have to do as super-user:

bash$ sudo emacs /etc/fstab

Adding these two lines:

yggdrasil:/yggnfs       /yggnfs                 nfs     defaults        0 0
debugfs                 /debug                  debugfs defaults        0 0
devnull:/users          /users                  nfs     defaults   0 0
devnull:/tools          /tools                  nfs     defaults   0 0
devnull:/projects       /projects               nfs     defaults   0 0

Create the directories /debug and /yggnfs, and mount the file systems:

bash$ sudo mkdir /debug /yggnfs
bash$ sudo mount -a
  • Note: In the case that you are unfamiliar with Linux, the forward slash ‘/’ before the directories specify that these directories will be created and mounted in the root directory.

Setup

Turn off the YUM updates daemon, and use chkconfig so that it is not turned on again at reboot:

bash$ sudo service yum-updatesd stop
bash$ sudo chkconfig --level 345 yum-updatesd off

If you are using KUSP Clock Synchronization, see the CLKSYNC Testbed Setup for setting up CLKSYNC on your testbed.

KUSP Kernel

Kernel installation is easy. Simply navigate to your kernel’s build directory and:

bash$ sudo make modules_install
bash$ sudo make install

Then edit /boot/grub/menu.lst or /boot/grub/grub.conf depending on which your machine’s distribution uses, so that the default kernel is the one you want to test (the first kernel listed is index 0):

default=X

and reboot. The kernel you test is made the default so that it will boot that kernel without you explicitly choosing the new kernel from the boot menu and thus so you will not have to be at the console of the machine. This is convenient when using ITTC testbed machines that are in the cold room. If the kernel fails to boot, you will need to see the console to consider any warning or error messages, or to choose another kernel to get the machine running.

At ITTC we have the testbeds set up on KVM switches connected to a specific terminal, and it is also possible to use netconsole with some additional setup,as described her: ` Remote Testbed Access <remote_testbed_access>`_.

Table Of Contents

Previous topic

Building the KUSP Software

Next topic

Initial Data Streams Tutorial Sequence

This Page