[lustre-discuss] [EXTERNAL EMAIL] Re: Building lustre client on Debian fails

[Tancheff, Shaun]

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