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" <[email protected] on behalf of [email protected]> 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" <[email protected] on behalf of [email protected]> 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 > [email protected] > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org > _______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
