[lustre-discuss] [EXTERNAL EMAIL] Re: [EXTERNAL EMAIL] Re: Building lustre client on Debian fails
Jan Andersen
jan at comind.io
Mon Oct 2 05:51:22 PDT 2023
Yes, that worked! Thanks again.
/jan
On 02/10/2023 10:06, Tancheff, Shaun wrote:
> Not to worry.
> Clients do not care what the server uses for backing disk (ldiskfs or zfs).
>
> It is technically redundant ... when --disable-server is specified ldiskfs and zfs are also disabled.
>
> On 10/2/23, 3:25 PM, "lustre-discuss on behalf of Jan Andersen" <lustre-discuss-bounces at lists.lustre.org on behalf of jan at comind.io> wrote:
>
> Hi Shaun,
>
> Thank you your reply. What you say about Debian 12 is a bit worrying: "--disable-ldiskfs" - I use ldiskfs on the servers, I hope this isn't relevant on the clients?
>
> /jan
>
> On 30/09/2023 09:15, Tancheff, Shaun wrote:
> > I tried Debian 5.10.0-22 kernel and had no issues with tag 2.15.3.
> >
> > I also checked Debian 12 (6.1.0-10) with gcc 12 and I hit a couple of things:
> > 2.15.3 seems to have some problems in configure
> > Master needs to disable gss [--disable-gss --disable-gss-keyring]
> > Lutf fails due to python deprecating Py_SetProgramName()
> > Several places hit "__write_overflow_field(p_size_field, size)" coming from OBD_FREE_PTR() which calls memset().
> >
> > FWIW my client build configure looks like:
> >
> > ./configure --config-cache --disable-server --enable-client --with-linux=/usr/src/linux-headers-6.1.0-10-amd64 --without-zfs --disable-ldiskfs --disable-gss --disable-gss-keyring --disable-snmp --enable-modules
> >
> > I pushed Lustre fixes for Debian's 6.1 kernel (client):
> > LU-17161 build: Avoid fortify_memset in OBD_FREE_PTR
> > LU-17160 build: Use PyConfig_InitPythonConfig 3.11 and later
> >
> > Regards,
> > Shaun
> >
> >
> > On 9/29/23, 11:00 PM, "lustre-discuss on behalf of Jan Andersen" <lustre-discuss-bounces at lists.lustre.org on behalf of jan at comind.io> wrote:
> >
> > I have a lustre 2.15.3 cluster and need to add Debian 11 and -12 clients. This is what I've done so far:
> >
> > # git clone git://git.whamcloud.com/fs/lustre-release.git
> > # git checkout 2.15.3
> > # sh autogen.sh
> > # ./configure --disable-server
> >
> > But make fails:
> >
> > ...
> > make[3]: Entering directory '/usr/src/linux-headers-5.10.0-13-amd64'
> > CC [M] /root/Downloads/linux/lustre-release/lnet/klnds/o2iblnd/o2iblnd.o
> > In file included from /usr/src/linux-source-5.10/include/linux/init.h:5,
> > from /usr/src/linux-headers-5.10.0-13-common/arch/x86/include/asm/mem_encrypt.h:15,
> > from /usr/src/linux-source-5.10/include/linux/mem_encrypt.h:17,
> > from /usr/src/linux-headers-5.10.0-13-common/arch/x86/include/asm/page_types.h:7,
> > from /usr/src/linux-headers-5.10.0-13-common/arch/x86/include/asm/page.h:9,
> > from /root/Downloads/linux/lustre-release/lnet/klnds/o2iblnd/o2iblnd.c:36:
> > /usr/src/linux-source-5.10/include/linux/sched/signal.h: In function ‘signal_pending’:
> > /usr/src/linux-source-5.10/include/linux/sched/signal.h:369:39: error: ‘TIF_NOTIFY_SIGNAL’ undeclared (first use in this function)
> > 369 | if (unlikely(test_tsk_thread_flag(p, TIF_NOTIFY_SIGNAL)))
> > | ^~~~~~~~~~~~~~~~~
> > /usr/src/linux-source-5.10/include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’
> > 78 | # define unlikely(x) __builtin_expect(!!(x), 0)
> > | ^
> >
> >
> > The system is Debian 11:
> >
> > # uname -r
> > 5.10.0-13-amd64
> > # ll /usr/src
> > total 117916
> > drwxr-xr-x 2 root root 4096 Aug 21 09:19 linux-config-5.10/
> > drwxr-xr-x 4 root root 4096 Jul 25 2022 linux-headers-5.10.0-12-amd64/
> > drwxr-xr-x 4 root root 4096 Jul 25 2022 linux-headers-5.10.0-12-common/
> > drwxr-xr-x 4 root root 4096 Jul 25 2022 linux-headers-5.10.0-13-amd64/
> > drwxr-xr-x 4 root root 4096 Jul 25 2022 linux-headers-5.10.0-13-common/
> > drwxr-xr-x 4 root root 4096 Aug 11 09:59 linux-headers-5.10.0-24-amd64/
> > drwxr-xr-x 4 root root 4096 Aug 11 09:59 linux-headers-5.10.0-24-common/
> > drwxr-xr-x 4 root root 4096 Aug 21 09:19 linux-headers-5.10.0-25-amd64/
> > drwxr-xr-x 4 root root 4096 Aug 21 09:19 linux-headers-5.10.0-25-common/
> > lrwxrwxrwx 1 root root 24 Jun 30 2022 linux-kbuild-5.10 -> ../lib/linux-kbuild-5.10
> > -rw-r--r-- 1 root root 161868 Aug 16 21:52 linux-patch-5.10-rt.patch.xz
> > drwxr-xr-x 25 root root 4096 Jul 14 21:24 linux-source-5.10/
> > -rw-r--r-- 1 root root 120529768 Aug 16 21:52 linux-source-5.10.tar.xz
> > drwxr-xr-x 2 root root 4096 Jan 30 2023 percona-server/
> > lrwxrwxrwx 1 root root 28 Jul 29 2022 vboxhost-6.1.36 -> /opt/VirtualBox/src/vboxhost
> > lrwxrwxrwx 1 root root 32 Apr 17 19:32 vboxhost-7.0.8 -> ../share/virtualbox/src/vboxhost
> >
> > Is this yet another case of the kernel sources having to be exactly the same as the running kernel?
> > It seems to be a bit difficult to determine whether the source version is correct or not; I haven't
> > found a Debian source tree that matches precisely.
> >
> > /jan
> > _______________________________________________
> > lustre-discuss mailing list
> > lustre-discuss at lists.lustre.org
> > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
> >
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>
More information about the lustre-discuss
mailing list