Re: [lustre-discuss] Static lfs?

2018-03-23 Thread Patrick Farrell 
Another off list note pointing out that lfs is likely a script now.  So here's 
the bitter end:


Ah, it looks like you're correct.  There's still an lfs.c but it no longer 
generates the "lfs" executable as it previously - Instead there's a lengthy and 
complex script named "lfs" which is not invoked by "make", but only during the 
install process.  That generates the lfs binary that is actually installed...

Uck.  Well, I found where it squirrels away the real binary when executed.

Run the script lustre/utils/lfs in your build dir, and it will start lfs.  Quit 
it, and you will find the actual lfs binary in lustre/utils/.libs/lt-lfs

Maybe this particular bit of build tooling would be clearer if it didn't try to 
pretend it didn't exist by apeing the binary without actually being it?

Thanks to John Bauer for help with this.



From: lustre-discuss  on behalf of 
Patrick Farrell 
Sent: Friday, March 23, 2018 3:17:14 PM
To: lustre-discuss@lists.lustre.org
Subject: Re: [lustre-discuss] Static lfs?


Ah, interesting – I got a question off list about this, but I thought I’d reply 
here.



‘ldd’ on the lfs binary says “not a dynamic executable”.



So it seems I’m confused (never was much for compilers and linkers).  Here are 
the errors I get trying to run it on another node:
./lfs: line 202: cd: /home/build/paf/[……..]/lustre/utils: No such file or 
directory

gcc: error: lfs.o: No such file or directory

gcc: error: lfs_project.o: No such file or directory

gcc: error: ./.libs/liblustreapi.so: No such file or directory

gcc: error: ../../lnet/utils/lnetconfig/.libs/liblnetconfig.so



From: lustre-discuss  on behalf of 
Patrick Farrell 
Date: Friday, March 23, 2018 at 3:03 PM
To: "lustre-discuss@lists.lustre.org" 
Subject: [lustre-discuss] Static lfs?



Good afternoon,



I’ve got a developer question that perhaps someone has some insight on.  After 
some recent (a few months ago now) changes to make the Lustre libraries and 
utilities build dynamically linked rather than statically linked, I’ve got a 
problem.  If I build an lfs binary just by doing “make”, the resultant binary 
looks for various libraries in the build directories and cannot be run on any 
system other than the one it was built on (well, I guess without replicating 
the build directory structure).  When doing make rpms and installing the RPMs, 
it works fine.  The problem is “make rpms” takes ~5 minutes, as opposed to ~1 
second for “make” in /utils.  (I assume “make install” works too, but I 
explicitly need to test on nodes other than the one where I’m doing the build, 
so that’s not an option.)



Does anyone have any insight on a way around this for a developer?  Either some 
tweak I can make locally to get static builds again, or some fix to make that 
would let the dynamically linked binary from “make” have correct library paths? 
 (To be completely clear: The dynamically linked binary from “make” looks for 
libraries in the locations where they are built, regardless of whether or not 
they’re already installed in the normal system library locations.)



Regards,

Patrick Farrell


___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] Static lfs?

2018-03-23 Thread Patrick Farrell 
Ah, interesting – I got a question off list about this, but I thought I’d reply 
here.

‘ldd’ on the lfs binary says “not a dynamic executable”.

So it seems I’m confused (never was much for compilers and linkers).  Here are 
the errors I get trying to run it on another node:
./lfs: line 202: cd: /home/build/paf/[……..]/lustre/utils: No such file or 
directory
gcc: error: lfs.o: No such file or directory
gcc: error: lfs_project.o: No such file or directory
gcc: error: ./.libs/liblustreapi.so: No such file or directory
gcc: error: ../../lnet/utils/lnetconfig/.libs/liblnetconfig.so

From: lustre-discuss  on behalf of 
Patrick Farrell 
Date: Friday, March 23, 2018 at 3:03 PM
To: "lustre-discuss@lists.lustre.org" 
Subject: [lustre-discuss] Static lfs?

Good afternoon,

I’ve got a developer question that perhaps someone has some insight on.  After 
some recent (a few months ago now) changes to make the Lustre libraries and 
utilities build dynamically linked rather than statically linked, I’ve got a 
problem.  If I build an lfs binary just by doing “make”, the resultant binary 
looks for various libraries in the build directories and cannot be run on any 
system other than the one it was built on (well, I guess without replicating 
the build directory structure).  When doing make rpms and installing the RPMs, 
it works fine.  The problem is “make rpms” takes ~5 minutes, as opposed to ~1 
second for “make” in /utils.  (I assume “make install” works too, but I 
explicitly need to test on nodes other than the one where I’m doing the build, 
so that’s not an option.)

Does anyone have any insight on a way around this for a developer?  Either some 
tweak I can make locally to get static builds again, or some fix to make that 
would let the dynamically linked binary from “make” have correct library paths? 
 (To be completely clear: The dynamically linked binary from “make” looks for 
libraries in the locations where they are built, regardless of whether or not 
they’re already installed in the normal system library locations.)

Regards,
Patrick Farrell

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

[lustre-discuss] Static lfs?

2018-03-23 Thread Patrick Farrell 
Good afternoon,

I’ve got a developer question that perhaps someone has some insight on.  After 
some recent (a few months ago now) changes to make the Lustre libraries and 
utilities build dynamically linked rather than statically linked, I’ve got a 
problem.  If I build an lfs binary just by doing “make”, the resultant binary 
looks for various libraries in the build directories and cannot be run on any 
system other than the one it was built on (well, I guess without replicating 
the build directory structure).  When doing make rpms and installing the RPMs, 
it works fine.  The problem is “make rpms” takes ~5 minutes, as opposed to ~1 
second for “make” in /utils.  (I assume “make install” works too, but I 
explicitly need to test on nodes other than the one where I’m doing the build, 
so that’s not an option.)

Does anyone have any insight on a way around this for a developer?  Either some 
tweak I can make locally to get static builds again, or some fix to make that 
would let the dynamically linked binary from “make” have correct library paths? 
 (To be completely clear: The dynamically linked binary from “make” looks for 
libraries in the locations where they are built, regardless of whether or not 
they’re already installed in the normal system library locations.)

Regards,
Patrick Farrell

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] Lustre client 2.10.3 build/install problem on Centos 6.7

2018-03-23 Thread Alex Vodeyko 
Leo thanks a lot!

The problem was that I somehow worked with lustre-2.10.3-1.src.rpm
from el7 tree! ((
The one from the link below built and updated perfectly

Thanks again and sorry for such a mistake,
Alex


2018-03-23 20:12 GMT+03:00 Leonardo Saavedra :
>
> On 03/23/2018 12:30 AM, Alex Vodeyko wrote:
>
> https://downloads.hpdd.intel.com/public/lustre/lustre-2.10.3/el6/client/SRPMS/lustre-2.10.3-1.src.rpm
>
<..>
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] Lustre client 2.10.3 build/install problem on Centos 6.7

2018-03-23 Thread Leonardo Saavedra 

On 03/23/2018 12:30 AM, Alex Vodeyko wrote:

Hi,

I'm trying to build/install Lustre 2.10.3 client on Centos 6.7.
"rpmbuild --rebuild --without servers lustre/lustre-2.10.3-1.src.rpm" 
goes fine, but
"yum localupdate kmod-lustre-client-2.10.3-1.el6.x86_64.rpm 
lustre-client-2.10.3-1.el6.x86_64.rpm" failed with:
Error: Package: kmod-lustre-client-2.10.3-1.el6.x86_64 
(/kmod-lustre-client-2.10.3-1.el6.x86_64)

           Requires: kernel >= 3.10.0-693


  

Centos 6.7 provides kernel series 2.6.32-* and it seems you are trying 
to build the lustre-client for centos/redhat 7.x (kernel 3.10.0-*)


maybe you should try with:

https://downloads.hpdd.intel.com/public/lustre/lustre-2.10.3/el6/client/SRPMS/lustre-2.10.3-1.src.rpm

[lsaavedr@testupd /tmp]$ wget -c 
https://downloads.hpdd.intel.com/public/lustre/lustre-2.10.3/el6/client/SRPMS/lustre-2.10.3-1.src.rpm


[root@testupd ~]# rpmbuild  --rebuild --without servers 
/tmp/lustre-2.10.3-1.src.rpm

Installing /tmp/lustre-2.10.3-1.src.rpm
[...]
Requires: /bin/bash /usr/bin/perl perl(File::Path) perl(Getopt::Long) 
perl(Getopt::Std) perl(POSIX)

Processing files: lustre-client-debuginfo-2.10.3-1.el6.x86_64
Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/root/kernel/rpmbuild/BUILDROOT/lustre-2.10.3-1.x86_64
Wrote: 
/root/kernel/rpmbuild/RPMS/x86_64/lustre-client-2.10.3-1.el6.x86_64.rpm
Wrote: 
/root/kernel/rpmbuild/RPMS/x86_64/kmod-lustre-client-2.10.3-1.el6.x86_64.rpm
Wrote: 
/root/kernel/rpmbuild/RPMS/x86_64/lustre-client-tests-2.10.3-1.el6.x86_64.rpm
Wrote: 
/root/kernel/rpmbuild/RPMS/x86_64/kmod-lustre-client-tests-2.10.3-1.el6.x86_64.rpm
Wrote: 
/root/kernel/rpmbuild/RPMS/x86_64/lustre-iokit-2.10.3-1.el6.x86_64.rpm
Wrote: 
/root/kernel/rpmbuild/RPMS/x86_64/lustre-client-debuginfo-2.10.3-1.el6.x86_64.rpm

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.G2e68o

[root@testupd ~]# rpm -Uvh 
/root/kernel/rpmbuild/RPMS/x86_64/lustre-client-2.10.3-1.el6.x86_64.rpm 
/root/kernel/rpmbuild/RPMS/x86_64/kmod-lustre-client-2.10.3-1.el6.x86_64.rpm

Preparing... ### [100%]
   1:kmod-lustre-client ### [ 50%]
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol libcfs_next_nidstring
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol lprocfs_stats_collector
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol ktime_get_real_seconds
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol libcfs_nid2str_r
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol ktime_get_seconds
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol lprocfs_str_to_s64
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol libcfs_next_nidstring
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol lprocfs_stats_collector
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol ktime_get_real_seconds
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol libcfs_nid2str_r
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol ktime_get_seconds
WARNING: 
/lib/modules/2.6.32-696.23.1.el6.x86_64/extra/lustre-client/fs/ptlrpc_gss.ko 
needs unknown symbol lprocfs_str_to_s64

   2:lustre-client ### [100%]
[root@testupd ~]#

---
Leo Saavedra
NRAO

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] Lustre client 2.10.3 build/install problem on Centos 6.7

2018-03-23 Thread Alexander I Kulyavtsev 
There are detailed build instructions on lustre.org wiki :
http://wiki.lustre.org/Compiling_Lustre

I built, installed and lustre client 2.10.3 works on SLF 6.x as below:

> $ cat /etc/redhat-release 
> Scientific Linux Fermi release 6.9 (Ramsey)
> $ uname -r
> 2.6.32-696.1.1.el6.x86_64

> $ cat /etc/redhat-release 
> Scientific Linux Fermi release 6.8 (Ramsey)
> $ uname -r
> 2.6.32-642.15.1.el6.x86_64

Build script (in-kernel IB) to build lustre client to be installed on the same 
host:

> $ cat lcb.inkernel-ib.sh 
> 
> #!/bin/bash
> 
> DIR=../downloads/downloads.hpdd.intel.com
> SRPM=lustre-2.10.3-1.src.rpm
> 
> rpmbuild  --rebuild --without servers --with lnet-dlc --with lustre-utils 
> $DIR/$SRPM
> 

Essentially this is the command you use.
There are extra arguments if you compile for different kernel, e.g. building on 
node with 3.10 for older kernel 2.6.32 .

It looks like you are trying to install lustre client module built with newer 
kernel.  Take a look at build logs.

You have to install kernel-devel rpm for your kernel on build node.

Alex.

> On Mar 23, 2018, at 1:30 AM, Alex Vodeyko  wrote:
> 
> Hi,
> 
> I'm trying to build/install Lustre 2.10.3 client on Centos 6.7.
> "rpmbuild  --rebuild --without servers lustre/lustre-2.10.3-1.src.rpm" goes 
> fine, but 
> "yum localupdate kmod-lustre-client-2.10.3-1.el6.x86_64.rpm 
> lustre-client-2.10.3-1.el6.x86_64.rpm" failed with:
> Error: Package: kmod-lustre-client-2.10.3-1.el6.x86_64 
> (/kmod-lustre-client-2.10.3-1.el6.x86_64)
>Requires: kernel >= 3.10.0-693
> 
> Building and installing on the same system with 2.6.32-696.10.2.el6.x86_64 
> kernel.
> 
> Same procedure worked fine on the same system with lustre 2.10.1 client.
> 
> Could you please help with it?
> 
> Thanks,
> Alex
> 
> 
> 
> ___
> lustre-discuss mailing list
> lustre-discuss@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org