Adding 3rd-party Software#

An existing compute node image may need to contain additional software (e.g., a driver and perhaps the driver's associated software) that has been downloaded from a 3rd-party vendor in the form of an RPM or a tarball.

Suppose a tarball named driver-tarball.tgz has been downloaded into the head node /tmp/ directory, and you need to install its contents into an image. A cautious first step is to clone an existing image and add the new software to that clone, which leaves the existing image unmodified. For example, clone a new image:

scyld-imgctl -i DefaultImage clone name=UpdatedImage

Now enter the new UpdatedImage in a chroot environment:

scyld-modimg -i UpdatedImage --chroot

Suppose your administrator user name is admin1. Inside the chroot you are always user root. Copy the downloaded tarball from the head node into your chroot with a simple command from inside the chroot:

scp -r admin1@localhost:/tmp/driver-tarball.tgz /tmp

Unpack /tmp/driver-tarball.tgz and examine the contents, where you will likely find a script that manages the tarball-specific software installation.

Important

Carefully read the instructions provided by the 3rd-party software vendor before executing the script, and carefully read the output produced when executing the script.

There are several factors to keep in mind when executing the 3rd-party install script:

  • A 3rd-party installation that involves a new kernel module requires linking that module to the kernel in the chroot. This requires the presence of the kernel-devel package that matches that kernel. If that RPM is not currently installed in the chroot, then inside the chroot manually yum install it, naming the specific kernel version, e.g.,:

    yum install kernel-devel-3.10.0-957.27.2.el7.x86_64

    to match kernel-3.10.0-957.27.2.el7.x86_64.

  • Some 3rd-party install scripts use the uname command to determine the kernel against which to link a new kernel module. However, when the uname command executes inside a chroot, it actually reports the kernel version of the host system that executes the scyld-modimg --chroot command, not the kernel that has been installed inside the chroot. This uname behavior only works properly for module linking purposes if the chroot contains only one kernel and if that kernel matches the kernel on the scyld-modimg --chroot-executing server. To specify an alternate kernel, either name that kernel as an optional argument of a --chroot argument, e.g.,:

    scyld-modimg -i NewImage --chroot 3.10.0-1160.45.1.el7.x86_64

    or as a KVER variable value using the --exec argument, e.g., for a script inside the image that initializes a software driver module and links that module to a specific kernel:

    scyld-modimg -i NewImage --execute 'KVER=3.10.0-1160.45.1.el7.x86_64 /path/to/script'

    Otherwise, hopefully the 3rd-party install script supports an optional argument that specifies the intended kernel version, such as:

    /path/to/install-script -k 3.10.0-1160.45.1.el7.x86_64

  • If the 3rd-party install script encounters a missing dependency RPM, then the script reports the missing package name(s) and fails. You must manually yum install those missing RPM(s) within the chroot and reexecute the script.

  • Some 3rd-party install scripts replace RPMs that were installed from the base distribution, e.g., Infiniband, OFED. If any currently installed ICE ClusterWare™ packages declare these base distribution packages as dependencies, then the install script's attempt to replace those packages fails. You must then uninstall the specified ClusterWare package(s) (e.g., openmpi3.1, openmpi3.1-intel), then retry executing the install script. In some cases the 3rd-party tarball contains packages that replace the ClusterWare package(s). In other cases you can reinstall these ClusterWare package(s) after the 3rd-party install script successfully completes.

Finally, exit the chroot and specify to Keep changes, Replace local image, Upload image, and Replace remote image.