ZoL 2.0 on Leap 15.1?
Hi all, I just noticed that ZFS / ZoL 2.0 has been packaged for Leap 15.1 [1]. Thanks! I am running a few production machines with Leap 15.1 and ZoL 0.8.x and I am considering to update to ZoL 2.0. Has anyone already made any real-world experiences with this update and the new packages on Leap 15.1 (or 15.2 for that matter)? Sebastian 1: http://download.opensuse.org/repositories/filesystems/openSUSE_Leap_15.1/x86...
Hi! On 12/15/20 9:17 AM, Sebastian M. Ernst wrote:
I just noticed that ZFS / ZoL 2.0 has been packaged for Leap 15.1 [1]. Thanks!
I am running a few production machines with Leap 15.1 and ZoL 0.8.x and I am considering to update to ZoL 2.0. Has anyone already made any real-world experiences with this update and the new packages on Leap 15.1 (or 15.2 for that matter)?
I was playing around this yesterday as well and noticed there was no DKMS kernel package on openSUSE but only a package with precompiled modules. Anyone knows why? DKMS is very handy as it makes switching kernels more flexible. With the zfs-kmp-default package, I'm getting ZFS modules for the latest kernel only unless I'm searching through the package archive. Adrian
On Di, 2020-12-15 at 09:55 +0100, John Paul Adrian Glaubitz wrote:
Hi!
On 12/15/20 9:17 AM, Sebastian M. Ernst wrote:
I just noticed that ZFS / ZoL 2.0 has been packaged for Leap 15.1 [1]. Thanks!
I am running a few production machines with Leap 15.1 and ZoL 0.8.x and I am considering to update to ZoL 2.0. Has anyone already made any real-world experiences with this update and the new packages on Leap 15.1 (or 15.2 for that matter)?
I was playing around this yesterday as well and noticed there was no DKMS kernel package on openSUSE but only a package with precompiled modules.
Anyone knows why? DKMS is very handy as it makes switching kernels more flexible. With the zfs-kmp-default package, I'm getting ZFS modules for the latest kernel only unless I'm searching through the package archive.
OTOH, one KMP will work not just for one kernel, but for all KABI- compatible kernels. And you are able to have KMPs for multiple incompatible kernels installed at the same time, if you really need that. In general, unless you compile your kernel yourself, you should be doing just fine with the KMP. Regards, Martin
On Jun 7, 2021, at 5:17 PM, Martin Wilck <martin.wilck@suse.com> wrote:
OTOH, one KMP will work not just for one kernel, but for all KABI- compatible kernels.
DKMS modules are built per kernel ABI version, not for every kernel version. So, this argument is moot.
And you are able to have KMPs for multiple incompatible kernels installed at the same time, if you really need that.
DKMS does that, too.
In general, unless you compile your kernel yourself, you should be doing just fine with the KMP.
I don’t remember what my problem was half a year ago, but pretty sure that this didn’t work properly when I tested. But anyway, I installed that machine with Debian in the end as I need a working Multi-Arch environment for cross-compiling which still doesn’t work on openSUSE, unfortunately. Adrian
On Mo, 2021-06-07 at 15:29 +0000, Adrian Glaubitz wrote:
In general, unless you compile your kernel yourself, you should be doing just fine with the KMP.
I don’t remember what my problem was half a year ago, but pretty sure that this didn’t work properly when I tested.
It depends on whether the KMP sets Provides: multiversion(kernel) Whether or not this is desirable can't be universally decided. For environments with many kernel updates (factory) it makes sense, for SLE it rather doesn't. Martin
On 07.06.2021 18:29, Adrian Glaubitz wrote:
On Jun 7, 2021, at 5:17 PM, Martin Wilck <martin.wilck@suse.com> wrote:
OTOH, one KMP will work not just for one kernel, but for all KABI- compatible kernels.
DKMS modules are built per kernel ABI version, not for every kernel version.
Could you elaborate? dkms will recognize if module are present in current kernel as weak update and skip build in this case. But as far as I can tell dkms checks for /sbin/weak-modules or /usr/lib/module-init-tools/weak-modules neither of which is present in Leap (looking at Leap 15.3 and dkms from openSUSE:Backports:SLE-15-SP3). dkms will use $WEAK_MODULES_BIN but it does not look like it is set either. I may have missed something?
So, this argument is moot.
Well, KMP is built when kernel-flavor is installed (strictly speaking when kernel-flavor-devel is installed) while dkms runs on next reboot with new kernel. If dkms modules are needed to access root how is dkms supposed to work? Are there any hooks *in openSUSE* to run dkms during kernel installation?
But anyway, I installed that machine with Debian in the end as I need a working Multi-Arch environment for cross-compiling which still doesn’t work on openSUSE, unfortunately.
Well, Debian has /etc/kernel; you cannot compare Debian and openSUSE. How to execute arbitrary script during kernel (package) installation on openSUSE?
On Mon, Jun 7, 2021 at 1:51 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On 07.06.2021 18:29, Adrian Glaubitz wrote:
On Jun 7, 2021, at 5:17 PM, Martin Wilck <martin.wilck@suse.com> wrote:
OTOH, one KMP will work not just for one kernel, but for all KABI- compatible kernels.
DKMS modules are built per kernel ABI version, not for every kernel version.
Could you elaborate? dkms will recognize if module are present in current kernel as weak update and skip build in this case. But as far as I can tell dkms checks for /sbin/weak-modules or /usr/lib/module-init-tools/weak-modules neither of which is present in Leap (looking at Leap 15.3 and dkms from openSUSE:Backports:SLE-15-SP3). dkms will use $WEAK_MODULES_BIN but it does not look like it is set either. I may have missed something?
There has never been any effort to support kABI tracking for DKMS. The kmod package doesn't have the weak-modules script like RHEL/CentOS does: https://git.centos.org/rpms/kmod/blob/792fc7f7d9518483d69b82757c9cab710c845e... -- 真実はいつも一つ！/ Always, there's only one truth!
On Mo, 2021-06-07 at 14:24 -0400, Neal Gompa wrote:
There has never been any effort to support kABI tracking for DKMS. The kmod package doesn't have the weak-modules script like RHEL/CentOS does: https://git.centos.org/rpms/kmod/blob/792fc7f7d9518483d69b82757c9cab710c845e...
You probably know, but as some readers who may not: weak-modules2 is part of the suse-module-tools package. I guess one *could* try to use it for DKMS-built modules. I've never tried. Martin
On So, 2021-06-13 at 09:29 +0300, Andrei Borzenkov wrote:
On 07.06.2021 23:09, Martin Wilck wrote:
You probably know, but as some readers who may not: weak-modules2 is part of the suse-module-tools package. I guess one *could* try to use it for DKMS-built modules. I've never tried.
It has different API than weak-modules (that was removed from suse-module-tools. Author sounds familiar ...)
weak-modules has been moved to suse-module-tools-legacy, which is still available (*). IIRC weak-modules had no users under (open)SUSE since Code 10. suse-module-tools is a basic package, I try to keep it small and only ship the necessary tools. So far I thought that weak-modules2's functionality was a superset of weak-modules. But I confess I didn't explore in depth. Can you explain what it's lacking? Regards Martin (*) I've indeed considered ditching it for good. I was unaware of the fact that people are still using weak-modules.
On Mon, Jun 14, 2021 at 10:00 AM Martin Wilck <martin.wilck@suse.com> wrote:
On So, 2021-06-13 at 09:29 +0300, Andrei Borzenkov wrote:
On 07.06.2021 23:09, Martin Wilck wrote:
You probably know, but as some readers who may not: weak-modules2 is part of the suse-module-tools package. I guess one *could* try to use it for DKMS-built modules. I've never tried.
It has different API than weak-modules (that was removed from suse-module-tools. Author sounds familiar ...)
weak-modules has been moved to suse-module-tools-legacy, which is still available (*). IIRC weak-modules had no users under (open)SUSE since
Well, I was not aware of weak updates support in DKMS either.
Code 10. suse-module-tools is a basic package, I try to keep it small and only ship the necessary tools.
So far I thought that weak-modules2's functionality was a superset of weak-modules. But I confess I didn't explore in depth. Can you explain what it's lacking?
It is just different calling conventions. dkms does list_each_installed_module "$module" "$kernelver" "$arch" | ${weak_modules} ${weak_modules_no_initrd} --add-modules and weak-modules2 does not have --add-modules option nor does it accept a list of modules on stdin.
On Mo, 2021-06-14 at 10:44 +0300, Andrei Borzenkov wrote:
On Mon, Jun 14, 2021 at 10:00 AM Martin Wilck <martin.wilck@suse.com> It is just different calling conventions. dkms does
list_each_installed_module "$module" "$kernelver" "$arch" | ${weak_modules} ${weak_modules_no_initrd} --add-modules
and weak-modules2 does not have --add-modules option nor does it accept a list of modules on stdin.
Right. It expects KMPs as input, not bare .ko files. There's the --add-kernel-modules option, but that doesn't create weak links, it' only meant for kernel-default-extra and the like. So, there _is_ some reason to keep weak-modules. In particular, dkms should require or at least recommend it. And we should set WEAK_MODULES_BIN in /etc/sysconfig/module-init-tools, as this is where DKMS looks for the tool. Can anyone confirm that DKMS actually *works* with weak-modules as shipped in the suse-module-tools-legacy package, if WEAK_MODULES_BIN=/usr/lib/module-init-tools/weak-modules is set? Martin
On Mon, Jun 14, 2021 at 11:11 AM Martin Wilck <martin.wilck@suse.com> wrote:
On Mo, 2021-06-14 at 10:44 +0300, Andrei Borzenkov wrote:
On Mon, Jun 14, 2021 at 10:00 AM Martin Wilck <martin.wilck@suse.com> It is just different calling conventions. dkms does
list_each_installed_module "$module" "$kernelver" "$arch" | ${weak_modules} ${weak_modules_no_initrd} --add-modules
and weak-modules2 does not have --add-modules option nor does it accept a list of modules on stdin.
Right. It expects KMPs as input, not bare .ko files. There's the --add-kernel-modules option, but that doesn't create weak links, it' only meant for kernel-default-extra and the like.
So, there _is_ some reason to keep weak-modules. In particular, dkms should require or at least recommend it. And we should set WEAK_MODULES_BIN in /etc/sysconfig/module-init-tools, as this is where DKMS looks for the tool.
Actually /usr/lib/module-init-tools/weak-modules is the default location where dkms looks for it.
Can anyone confirm that DKMS actually *works* with weak-modules as shipped in the suse-module-tools-legacy package, if WEAK_MODULES_BIN=/usr/lib/module-init-tools/weak-modules is set?
Martin
On 07.06.2021 23:09, Martin Wilck wrote:
On Mo, 2021-06-07 at 14:24 -0400, Neal Gompa wrote:
There has never been any effort to support kABI tracking for DKMS. The kmod package doesn't have the weak-modules script like RHEL/CentOS does: https://git.centos.org/rpms/kmod/blob/792fc7f7d9518483d69b82757c9cab710c845e...
You probably know, but as some readers who may not: weak-modules2 is part of the suse-module-tools package. I guess one *could* try to use it for DKMS-built modules. I've never tried.
It has different API than weak-modules (that was removed from suse-module-tools. Author sounds familiar ...) commit f53ea08691427630dc7440559392e2967bd5f7eb Author: Martin Wilck <mwilck@suse.com> Date: Fri May 21 20:00:47 2021 +0200 remove "weak-modules" script weak-modules has been in the "legacy" subpackage for 2 years. Remove it.
participants (6)
-
Adrian Glaubitz -
Andrei Borzenkov -
John Paul Adrian Glaubitz
-
Martin Wilck -
Neal Gompa -
Sebastian M. Ernst