Lustre RPM builds don't produce packages containing debuginfo for the Lustre kernel modules. This is because kernel modules are not marked as executable and so are ignored by find-debuginfo.sh. Based on the approach taken in the RHEL kernel.spec, I added the following to the end of the %install section:

# mark modules executable so that strip-to-file can strip them
find $RPM_BUILD_ROOT/lib/modules/%{kversion}/updates -name "*.ko" -type f | \
  xargs --no-run-if-empty chmod u+x

This done, debuginfo files for the kernel modules appear in lustre-debuginfo. I would have liked it if a lustre-modules-debuginfo package was automagically created by rpmbuild. But alas no. So can we live with a monolithic debuginfo package? After much introspection I have decided that I can.

I wish it were this simple, but there is an obnoxious bug in debugedit (see https://bugzilla.redhat.com/show_bug.cgi?id=304121) which may cause rpmbuild to fail if configure is given noncanonical paths to the o2ib tree (or others). In particular,

./configure --with-linux=/usr/src/linux-2.6.32-279.11.1.el6.lm.x86_64/ --with-o2ib=/opt/ofed/src/openib
make rpms

will succeed, while

./configure --with-linux=/usr/src/linux-2.6.32-279.11.1.el6.lm.x86_64/ --with-o2ib=/opt/ofed/src/openib/
make rpms

will fail with something like:

...
extracting debug info from /root/rpmbuild/BUILDROOT/lustre-2.3.54-2.6.32_279.11.1.el6.lm.x86_64_g7f57b6a.x86_64/lib/modules/2.6.32-279.11.1.el6.lm.x86_64/updates/kernel/net/lustre/ko2iblnd.ko
/usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character
error: Bad exit status from /var/tmp/rpm-tmp.pTyzxn (%install)

This could be addressed, say, by doing path c14n in lnet/autoconf/lustre-lnet.m4. I assume that the same would apply to qsnet, portals, rapid array, model railroad, and all of the other LNDs whose names I forget.

Similarly lustre-ldiskfs-debuginfo is created but empty.

I admit that this adds some complexity/fragility to lustre.spec but the benefits are easily seen by anyone who runs "perf top" on a busy lustre client.

I welcome suggestions as I continue to poke at this.