Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

Debugging an NMI Build

Sometimes you need to debug a package on a platform only available under NMI. This is specifically when you expect to need to patch the package, not for debugging NMI problems. Here is the general strategy:

  1. Start with a failed build.
  2. You might want to nmi_pin it for the expected duration of your debugging.
  3. From the run directory locate the $PLATFORM_app_input.tar.gz. For example: x86_64_deb_5.0_app_input.tar.gz
    ssh nmi-s003
    cd /nmi/run/adesmet/2009/03/adesmet_nmi-s003.batlab.cs.wisc.edu_1238154320_9648
    ls -l x86_64_deb_5.0_app_input.tar.gz
  4. Copy that file to the platform in question.
    scp x86_64_deb_5.0_app_input.tar.gz nmi-0200:./
  5. Create a temporary directory to work in, and put the tarball there. (This is just an organizational step.)
    ssh nmi-0200
    mkdir voms-debugging
    cd voms-debugging
    mv ../x86_64_deb_5.0_app_input.tar.gz  ./
  6. Make a subdirectory called "userdir". It must be called userdir ('s fix_la_files() relies on it).
    mkdir userdir
    cd userdir
  7. Untar it
    tar xvf ../x86_64_deb_5.0_app_input.tar.gz
  8. Set NMI_PLATFORM to your platform.
    export NMI_PLATFORM=x86_64_deb_5.0
  9. Set the NMI_component (this is the "component" entry from the nmi/cmdfile)
    export NMI_component=voms
  10. For each step in the build, do the following. The steps are the "vdt_declare_tasks" in the nmi/cmdfile, while the executable ("" in this example) is the remote_task in nmi/cmdfile.
    Do this one step at a time until you hit your problem. At this point you can probably hand-run the command giving you problems as you debug and patch.