7.5. Inspecting and Changing PXE Behaviour

There are two parts to the Rocks database for modifying PXE behaviour: boot and bootaction. The "boot" part determines which logical action should be performed. The two common actions are "os" and "install." The second table is the bootaction table. This associates a logical action with a specific TFTP configuration.

Warning

It is possible to have commands affect all nodes. In this case use '%' as the host wildcard. For example rocks set host boot % action=install will cause ALL nodes to reinstall the next time they boot.

Note

For commands that take lists of hosts, it is possible to use an appliance type for the host(s) argument. rocks list appliance are the list of valid appliance types. To set the boot action of all compute appliances to be install, use rocks set host boot compute action=install.

The following illustrates how to inspect the current action of nodes and then the specifics of each action.

# rocks list host boot
HOST         ACTION 
vizzy:       os     
compute-0-0: os     
compute-0-1: os     
compute-1-0: os     
compute-1-1: install
compute-2-0: os     
compute-2-1: os 


# rocks list bootaction output-col=action,kernel     
ACTION               KERNEL                                     
install:             vmlinuz-5.2-i386                           
install headless:    vmlinuz-5.2-i386                           
memtest:             kernel memtest                             
os:                  localboot 0                                
pxeflash:            kernel memdisk bigraw                      
rescue:              vmlinuz-5.2-i386

In the above, all nodes are set to boot the "os", except for node compute-1-1. That node will call the boot action named "install". In the case the TFTP configuration file contain the details arguments of the listed in the install action. The command rocks list bootaction shows the details of each logical action.

7.5.1. Changing a logical PXE action

It is possible to override the details of a logical action on a per-node basis. Suppose that we wanted to make the logical action of "install" for compute-1-1 to be headless and to set a flag acpi=off. Then the following will accomplish this:

# rocks add bootaction action="install headless noacpi" kernel="vmlinuz-5.2-i386" ramdisk="initrd.img-5.2-i386" \
args="ks ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 headless vnc acpi=off"

# rocks set host installaction compute-1-1 action="install headless noacpi"

To inspect that the change is indeed specific to just compute-1-1, then do the following

# rocks list host compute-1-1
MEMBERSHIP   CPUS RACK RANK RUNACTION INSTALLACTION          
Compute      2    0    0    os        install headless noacpi

# rocks list host compute-1-0
MEMBERSHIP   CPUS RACK RANK RUNACTION INSTALLACTION
Compute      8    0    1    os        install

In the above, compute-1-1 has a specific override for its install action, where compute-1-0 still retains the default install action.

7.5.2. Running Memtest86

It is often useful to run the memory testing tool memtest86+ to determine if memory is valid. The straightforward way to accomplish this is to apply the following procedure (in our example case for host compute-1-1)

  1. # rocks set host runaction compute-1-1 action=memtest

    # rocks set host boot compute-1-1 action=os

  2. Boot node compute-1-1 by power cycle or other means.

  3. After compute-1-1 has successfully started the diagnostic, reset the runaction parameter:

    # rocks set host runaction compute-1-1 action=os