[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

[Jian Yu]

Patches landed.

[Jay Lan (Inactive)]

Hi Peter,

The above two ported patches did solve my problem.
Please land the patches and close this ticket.

Thanks!
Jay

[Peter Jones]

Jay

Try these two patches that have already been ported to the 2.7 FE branch

LU-6001: http://review.whamcloud.com/17678
LU-6697: http://review.whamcloud.com/17679

Peter

[Jay Lan (Inactive)]

Hi Minh, can you create a patch for 2.7.1?
Thanks!

[Minh Diep]

Jay, please apply this http://review.whamcloud.com/#/c/15181/ to see if it fixes

[Jay Lan (Inactive)]

Old version of lustre.spec.in would not work for 2.7.1 at all.
I will look into this problem later. I need to create lustre 2.7.1 server rpms for our developers.

So far, I hacked around the problems I have encountered.

[Jian Yu]

Hi Jay,

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.

Did you happen to use an old version of lustre.spec.in to build Lustre 2.7.1?

In Lustre 2.7.1 source codes:

$ grep llbackup * -rn | grep -v tags | grep -v doc
$ 

In Lustre 2.5.3 source codes:

$ grep llbackup * -rn | grep -v tags | grep -v doc
lustre/utils/Makefile.am:19:bin_scripts = llstat llobdstat plot-llstat llbackup
lustre.spec.in:353:%attr(-, root, root) %{_bindir}/llbackup
$

So, for Lustre 2.7.1, it would not hit the llbackup issue.

[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!