[LU-7541] rpm build failed in 2.7.1

• Type: Bug
• Resolution: Fixed
• Priority: Critical
• Affects Version/s: Lustre 2.7.0
• Environment: centos 7.1.
• Severity: 3
• Assignee: Jian Yu
• Reporter: Jay Lan (Inactive)

Description

When building lustre-2.7.1 rpms in a centos 7.1 chroot environment, the build failed:

...
if test -d "lustre-2.7.1"; then find "lustre-2.7.1" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf "lustre-2.7.1" ||

{ sleep 5 && rm -rf "lustre-2.7.1"; }

; else :; fi
rpmbuilddir=`mktemp t -d rpmbuild-lustre$USER-XXXXXXXX`; \
make \
rpmbuilddir="$rpmbuilddir" rpm-local || exit 1; \
/bin/rpmbuild \
--define "_tmppath $rpmbuilddir/TMP" \
--define "_topdir $rpmbuilddir" \
--define "build_src_rpm 1" \
--define "dist %

{nil}

" \
-ts lustre-2.7.1.tar.gz || exit 1; \
cp $rpmbuilddir/SRPMS/lustre-2.7.1-*.src.rpm . || exit 1; \
rm -rf $rpmbuilddir
make[1]: Entering directory `/tmp.chroot/nas-2.7.1-fe'
make[1]: Leaving directory `/tmp.chroot/nas-2.7.1-fe'
sed: can't read /lib/modules/2.6.32-358.6.2.el6.x86_64/build/include/linux/version.h: No such file or directory
error: line 138: Version required: Requires: kernel =
make: *** [srpm] Error 1

I did specify
--with-linux=/usr/src/kernels/${kversion} \
when running `configure`, so the path should be used instead of "/lib/modules/`uname -r`"

Also config.log showed the version.h exists at include/generated/uapi/linux/version.h:
...
configure:13640: checking for /usr/src/kernels/3.10.0-229.20.1.el7.20151203.x86_64.lustre271/include/linux/version.h
configure:13654: result: no
configure:13661: checking for /usr/src/kernels/3.10.0-229.20.1.el7.20151203.x86_64.lustre271/include/generated/uapi/linux/version.h
configure:13675: result: yes

I did not have this problem in 2.x.y build up to 2.5.3. Changes made in 2.7 broke my build.

I will attach config.log and log-rpms files.
:q

Issue Links

• is related to: LU-6697 build SRPM target should not depend from kernel sources
• is related to: LU-6001 cleanup build scripts after reorganization

Comments

[Jay Lan (Inactive)]

Thanks, I will take a look later to get the version.h problem resolved.

For now I simply copied the version.h to where the build process looks for and got it moving along.

Well, the build failed to find llbackup. Unfortunately, the file, used to be in lustre/utils/llbackup in 2.5.3, does not exist in 2.7.1.

If that file is pulled from 2.7.1, the build process should do so accordingly.

[Jian Yu]

Hi Jay,

I just checked the configure logs of passed build against Lustre 2.7.1 and also found:

checking for /var/lib/jenkins/workspace/lustre-b2_7_fe/arch/x86_64/build_type/server/distro/el7/ib_stack/inkernel/BUILD/reused/usr/src/kernels/3.10.0-229.14.1.el7_lustre.gc77f399.x86_64/include/linux/version.h... no
checking for /var/lib/jenkins/workspace/lustre-b2_7_fe/arch/x86_64/build_type/server/distro/el7/ib_stack/inkernel/BUILD/reused/usr/src/kernels/3.10.0-229.14.1.el7_lustre.gc77f399.x86_64/include/generated/uapi/linux/version.h... yes

So, it's no problem that version.h is located under include/generated/uapi/linux/.

And the configure command we used was:

./configure --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-linux=/var/lib/jenkins/workspace/lustre-b2_7_fe/arch/x86_64/build_type/server/distro/el7/ib_stack/inkernel/BUILD/reused/usr/src/kernels/3.10.0-229.14.1.el7_lustre.gc77f399.x86_64 --with-linux-obj=/var/lib/jenkins/workspace/lustre-b2_7_fe/arch/x86_64/build_type/server/distro/el7/ib_stack/inkernel/BUILD/reused/usr/src/kernels/3.10.0-229.14.1.el7_lustre.gc77f399.x86_64 --with-release=3.10.0_229.14.1.el7_lustre.gc77f399.x86_64 --enable-tests --enable-utils --enable-modules --with-kmp-moddir=extra

[Jay Lan (Inactive)]

Yes I did, Jian.
Thanks!

[Jian Yu]

Thank you, Jay.

For /usr/src/kernels/3.10.0-229.20.1.el7.20151203.x86_64.lustre271, did you patch the kernel with Lustre kernel patches and build it from source?

FYI, https://build.hpdd.intel.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.html#dbdoclet.50438210_65411

[Jay Lan (Inactive)]

Attached are two scripts:
nas-config.sh.mofed31.el71.271
nas-make.sh.el71.271

I ran the two scripts one after another.

[Jian Yu]

Hi Jay,

Could you please list the steps and commands you used for the building process? Thank you.

[Jay Lan (Inactive)]

$ ./configure --enable-tests --enable-mpitests=yes --with-o2ib=/usr/src/ofa_kernel/lustre271 --with-linux=/usr/src/kernels/3.10.0-229.20.1.el7.20151203.x86_64.lustre271 --with-linux-obj=/usr/src/kernels/3.10.0-229.20.1.el7.20151203.x86_64.lustre271 --with-downstream-release=1nasS_mofed31v1 --with-release=1nasS_mofed31v1_3.10.0-229.20.1.el7.20151203.x86_64.lustre271

I got the same error at building rpm.

[Jian Yu]

Hi Jay,

Could you please try adding "--with-linux-obj=/usr/src/kernels/3.10.0-229.20.1.el7.20151203.x86_64.lustre271" to run ./configure?

[Peter Jones]

Jay

Mahmoud is not the only one to find 2.7.x interesting

Jian

Could you please assist Jay?

Thanks

Peter

[Jay Lan (Inactive)]

Hi Peter,

You were right that this does not affect production systems. Please downgrade the priority.

Mahmoud wants to move to 2.7.1 after 2.5.3. There are features in 2.7 that Mahmoud wants and he is breathing on my neck.

[Peter Jones]

Jay

Am I correct in assuming that this is not an Sev1 (i.e site down) situation for NASA and you are in fact just exploring for a possible future upgrade?

Peter