-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
6.2.8 kernel revert needed for zfs-2.1.9 dkms #14658
Comments
That patch got originally added to 6.3-rc3 kernel and backported to 6.2.8 |
That's probably fixable, I would expect, based on reading the commit - I would guess that the difference is the signature change is making some kernel compat configure check fall back on something that's a GPL-only export now, and a simple update to that would resolve this... e: something like 3ace9de (untested on 6.2+, I don't have that tree laying around conveniently) e2: or more like the above plus 2e9c9b7 |
Same problem compiling from source. |
I confirm the issue on SlackWare Linux 15 x86_64 current compiling ZFS on 6.2.8 kernel. On Linux kernel 6.2.6 I haven't got any compilation issues. |
Same issue here. |
Same issue |
Both patches apply cleanly on 6.2.8, but no change in the build error, seems versions not used when applied to 6.2?
according to the patch, second line should be |
Did you regenerate with autogen.sh after applying before rerunning
configure?
Because at least for me, on the checkout of 2e9c9b7, on a 5.15 system:
configure:110409: checking whether 6.2+ bdev_*_io_acct() are available
configure:110424: result: no
configure:110426: checking whether pre-6.3 bdev_*_io_acct() are available
configure:110441: result: no
configure:110443: checking whether generic disk_*_io_acct() are available
configure:110450: result: yes
…On Thu, Mar 23, 2023 at 11:14 AM demmm ***@***.***> wrote:
That's probably fixable, I would expect, based on reading the commit - I
would *guess* that the difference is the signature change is making some
kernel compat configure check fall back on something that's a GPL-only
export now, and a simple update to that would resolve this...
e: something like 3ace9de
<3ace9de>
(untested on 6.2+, I don't have that tree laying around conveniently)
e2: or more like the above plus 2e9c9b7
<2e9c9b7>
Both patches apply cleanly on 6.2.8, but no change in the build error,
seems versions not used when applied to 6.2?
See messages:
checking whether blk_cleanup_disk() exists... no
checking whether generic bdev_*_io_acct() are available... no
checking whether generic disk_*_io_acct() are available... no
checking whether generic bio_*_io_acct() are available... yes
according to the patch, second line should be whether 6.2+
bdev_*_io_acct() are available
—
Reply to this email directly, view it on GitHub
<#14658 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABUI7ME5NXK7VDY2XWLGETW5RSD7ANCNFSM6AAAAAAWETO4DM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@rincebrain That was it (I thought it was enabled, but ended up being commented out), builds fine now. |
Linux 6.3+, and backports from it, changed the signatures on bdev_io_{start,end}_acct. Add a case for it. Fixes: openzfs#14658 Signed-off-by: Rich Ercolani <rincebrain@gmail.com>
Linux 6.3+, and backports from it, changed the signatures on bdev_io_{start,end}_acct. Add a case for it. Fixes: openzfs#14658 Signed-off-by: Rich Ercolani <rincebrain@gmail.com>
Linux 6.3+, and backports from it, changed the signatures on bdev_io_{start,end}_acct. Add a case for it. Fixes: openzfs#14658 Signed-off-by: Rich Ercolani <rincebrain@gmail.com>
Is it fairly common that Linux removes or prevents access to certain symbols that zfs relies on? I recall this happening in the past, with encryption primitives... |
Linux 6.3+, and backports from it, changed the signatures on bdev_io_{start,end}_acct. Add a case for it. Fixes: openzfs#14658 Signed-off-by: Rich Ercolani <rincebrain@gmail.com>
The kernel ABI is always a work in progress and it evolves as needed by the upstream kernel developers. This means for each new kernel release the OpenZFS code may need to be updated to accommodate recent kernel changes. It's for this reason OpenZFS includes an extensive set of configure checks to determine what interfaces are available. Generally speaking it's fairly uncommon for this kind of breaking change to be backported to a released kernel. When it does happen the fix usually involves updating our checks to detect the modified interface. That's in fact what happened in this case. It's much less common for an interface to be unexpectedly removed or converted in some way which makes it unavailable. However, it does happen on occasion and it's something to keep in mind if you're running a more bleeding edge kernel. This is far less likely to occur with any of the enterprise distributions (Ubuntu LTS, RHEL, SUSE, etc). We'll get this fixed up in the 2.1.10 release. |
Also, as a footnote, I don't believe it's ever been the case that OpenZFS
consumed the Linux kernel's crypto interfaces - you may be thinking of the
FPU interfaces.
…On Fri, Mar 24, 2023 at 5:51 PM Brian Behlendorf ***@***.***> wrote:
The kernel ABI is always a work in progress and it evolves as needed by
the upstream kernel developers. This means for each new kernel release the
OpenZFS code may need to be updated to accommodate recent kernel changes.
It's for this reason OpenZFS includes an extensive set of configure checks
to determine what interfaces are available.
Generally speaking it's fairly uncommon for this kind of breaking change
to be backported to a released kernel. When it does happen the fix usually
involves updating our checks to detect the modified interface. That's in
fact what happened in this case. It's much less common for an interface to
be unexpectedly removed or converted in some way which makes it
unavailable. However, it does happen on occasion and it's something to keep
in mind if you're running a more bleeding edge kernel. This is far less
likely to occur with any of the enterprise distributions (Ubuntu LTS, RHEL,
SUSE, etc).
We'll get this fixed up in the 2.1.10 release.
—
Reply to this email directly, view it on GitHub
<#14658 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABUI7JEQHUZA76HXQ73KMLW5YJPBANCNFSM6AAAAAAWETO4DM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I just cut #14668, but still don't have a 6.3 tree handy, could someone check that I didn't break it in cleaning up various style nits? |
Links against 6.2.8, but I want to make sure I build a fresh 6.3 before I test that. The last one I successfully built was rc1, and I don't know if they've changed anything significantly since then. That shouldn't take too long, though. |
I've tested to compile the above commit against 6.3rc3 and it did not work at all. Above commit against 6.2.8 worked fine. |
Pretty related to #14555. |
Not really, no. That's an AArch64-specific breakage that's unrelated except also in a new kernel. |
Is there anything I can do to help get this applied and released? I can't boot my machine because of this issue. |
Switching to the |
Not terribly useful to use LTS if you have bleeding edge hardware like I do. |
Also not useful if you've upgraded your pools to have features that aren't in the modules in the current |
Apply #14668 locally if you need this fixed more urgently than releases come out? If you want to run the latest kernel, there's always going to be a timelag between Linux merging breaking changes and them being fixed, in git or in a release branch, in OpenZFS, which is why I usually advise people don't run on a continuously-updating latest Linux kernel versus a known quantity if they need to rely on OpenZFS. |
Here it goes:
for "zfs_kernel6.2.8+.patch" it's there: |
Applied onto ZFS 2.1.9 and works wonderfully well here even with Linux 6.2.8. Good job @rincebrain. The aforementioned Gentoo bug #903117 is nothing more than changes brought in by PR #14668 put together in a single patch file. |
|
Fellow Arch user here, I also got bit by this. Currently using zfs-dkms on 6.2.8 with reverted b477180587d81a4dd756361098bd534dfa6bb53d. My thanks to @comrade-meowski for identifying the offending commit. I also use linux and not linux-lts because imho "LTS" is not really stable. Well, "stable" is not stable we just found out. ;-) There's a constant stream of backports introducing regressions, which then nobody figures out. In the tree close to what Torvalds releases, I think more testing is done. Since I need a bunch more kernel patches (debug symbols, wifi, mellanox, etc.) I use a script to build patched kernels through auto-patched PKGBUILDs anyway. Learned this trick to create a reversal patch from a forward patch: interdiff -q 628-zfs.patch /dev/null > 628-rev-zfs.patch To add, thanks for the advice to not discuss on LKML or elsewhere. Obliging... Just wish a big distro like Arch would upgrade ZFS to a first class citizen, possibly endorsing zfsbootmenu to boot zfs snapshots straight from a menu out of UEFI. Once people are hooked on snapshots, encryption, compression, CoW, checksums for everything, I'd hope upstream would no longer be able to ignore the only filesystem I trust. |
With the above linked PR, you don't need to modify the kernel in any way to use 6.2.8. Also, #14622 is relevant to further impending |
Yes, a PR for #14622 will soon be ready for review. Test suite run has passed on 6.3-rc2, now running on a 5.15 kernel. |
Linux 6.3+, and backports from it (6.2.8+), changed the signatures on bdev_io_{start,end}_acct. Add a case for it. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rich Ercolani <rincebrain@gmail.com> Closes openzfs#14658 Closes openzfs#14668
Linux 6.3+, and backports from it (6.2.8+), changed the signatures on bdev_io_{start,end}_acct. Add a case for it. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rich Ercolani <rincebrain@gmail.com> Closes openzfs#14658 Closes openzfs#14668
For those who just want a quick rundown of the steps involved, here is what I did (Fedora 37 Workstation): (Note that the system was previously building the zfs dkms package just fine, and so has all the necessary pre-requisites already installed, such as e.g., kernel-devel, etc) Thank you for the quick fix @rincebrain!
HTH |
In the title of this error dkms has been added but the problem is general: both using dkms and compiling directly without dkms. On the other hand, if this is fixed but you have not released a new version with this patch, I don't think the issue should be closed. With the current version 2.1.9 this still fails. When is it planned to release a version with the patch? |
For root on zfs users, I highly recommend adding a second kernel and a corresponding bootloader entry to have a fallback for cases exactly like this. It kind of saved me on friday. |
Linux 6.3+, and backports from it (6.2.8+), changed the signatures on bdev_io_{start,end}_acct. Add a case for it. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rich Ercolani <rincebrain@gmail.com> Closes openzfs#14658 Closes openzfs#14668
My home Fedora server has been bitten by this type of issue a couple times in the past — I know it can take ZFS a bit to catch up with kernel releases, so I've tried to be more careful about checking updates and not just blindly slapping them in. However, to keep from getting surprised, I've also done this and I recommend it to anyone on Fedora looking to make sure this doesn't bite them:
This will lock the kernel packages to the current version and prevent upgrades or removals. Once I've checked to make sure the next kernel rev is safe, I then run |
Update the ZFS submodule so that it includes a commit with compat fix [0] for kernel 6.2.8, which otherwise regressed build through the 484c2be84b49 ("block: count 'ios' and 'sectors' when io is done for bio-based device") commit, which was backported to stable-6.2 from the v6.3-rc3 "release". [0]: openzfs/zfs@59f1875 Link: openzfs/zfs#14658 Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Linux 6.3+, and backports from it (6.2.8+), changed the signatures on bdev_io_{start,end}_acct. Add a case for it. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rich Ercolani <rincebrain@gmail.com> Closes openzfs#14658 Closes openzfs#14668
The latest stable kernel 6.2.8 causes zfs-2.1.9 & zfs-2.1.10-staging to fail during dkms installation of the zfs modules.
The error given in the dkms make.log is:
Building 6.2.8 with commit b477180587d81a4dd756361098bd534dfa6bb53d reverted allows zfs dkms to complete normally again. I have only tested with dkms but presumably this will more generally stop zfs building against 6.2.8 at all.
This is the kernel commit:
The text was updated successfully, but these errors were encountered: