RPM: Hold back incompatible kernel packages on Fedora #17271
Conversation
tonyhutter
added
Type: Building
|
EDIT now that ive actually tested it. I think that we might actually need something more like tonyhutter@f606c29 to have DNF work reasonably. Use "Requires" and "Conflicts" for the kernel packages zfs actually requires, and just use "Conflicts" for most things it'll prevent ther new kernel packages from installing without breaking DNF and will not cause zfs-dkms to needlessly pull Details of "why" are in #17265 (#17265 (comment)), but basically Im hoping that by just using "Conflicts" for most things it'll prevent the incompatable new kernel packages from installing without breaking DNF and will not cause zfs-dkms to needlessly pull in all the kernel subpackages. Ive tested this and it seemingly makes everything work like it should on 2.3.1 with an available kernel 6.14.3 update. See #17265 (comment) for a more details. |
|
@tonyhutter - I made a PR with the changes described in my last comment to the tonyhutter/zfs branch that is the source of this PR. |
|
It's more of a formality, but I will need to add these for RHEL8 (RHEL9 uses kernel-modules-core): Let me do that and retest. |
tonyhutter
force-pushed
the
fedora-kernel-conflict
branch
2 times, most recently
from
2addcea to
1fbe3d7
Compare
|
I ended up refactoring this PR to just add... ... and nothing else. The 'kernel' dependency is typically provided by the 'kernel-core' package. That should be all we need to build the dkms packages on EL and Fedora. I'm pretty convinced this minimalist route is the best way to go. The alternative is add |
|
@tonyhutter - I see the appeal of the minamalist route. im less convinced, but this in probably a reasonable initial change to make. I guess my thoughts are that is that its less about "what zfs needs" and more about "not letting the system install stuff that will be broken as a direct result of things zfs is blocking". This is an incompatable kernel, and so (sort of by definition) zfs wont have what it needs until there is an update for zfs that supports the new kernel. In many ways, the existing behavior is the minimalist route - zfs blocks only what is needed to prevent building potentially broken zfs kernel modules and leaves everything else alone. And, ignoring everything other than zfs, it achieved this goal quite well. The issues caused werent really "problems with zfs", but were "problems from installing a kernel that couldnt build new modules on a system that uses locally-compiled kernel modules". I feel like blocking kernel-core but not blocking the rest of the kernel packages is sort of just trading one "problem stemming from a partially installed kernel" for another. Granted, installing things like That said, not having to constantly update the list of kernel subpackages to block and notr blocking stuff zfs never uses are both a big plus, and it should be much better than the current situation, and having something like |
You might have some stray kernel-related packages like
The
I don't think this would be the case. The modules* packages requre a specific kernel. Here's what I see on Fedora 41: |
|
I rebuilt the zfs-dkms rpm using the zfs-2.3-release branch with the patch you propose (using Requires + Conflicts for kervel-devel and kernel, but no other kernel packages explicitly listed). Running Looking into it, I think you also need to add a "Conflicts" for kernel-uki-virt. It seems that this package will provide the kernel-uname-r required by the kernel modules. Which is why dnf pulled tried to pull it in for me via "installing dependencies". Ill re-test adding a Conflicts line for kernel-uki-virt and report back |
|
UPDATE: adding on top of your patch seems to fix things. Running You still get updated kernel docs + kernel tools + kernel headers + perf, but i dont think those will cause problems. Also it doesnt try to remove an old working kernel, so as far as dnf is concerned you arent installing a new kernel. |
Ah that's annoying. Thanks for hunting down the issue though - I'll add in the |
Yeah...I missed that the first go around too (when adding kernel + kernel-core as Requires and Conflicts didnt work). That said, kernel-uki-virt seems to be Fedora's work-in-progress project for booting with unified kernel images. Id imagine that it isnt going anywhere and will probably start to get used more as the project gets everything ironed out (since GRUB-less UKI booting is fantastic). you probably want both kernel and kernel-uki-virt listed as Conflicts, but for requires you probably want it to be "requires at least one of them". Perhaps for the Requires dependencies you want something like which (assuming it works like it did with the kernel modules packages) would allow either the standard kernel or kernel-uki-virt to satisfy it. (EDIT: assuming zfs works fine with kernel-uki-virt) |
|
I think we can simplify all cases to just looking at |
I think this is the answer. As a bonus it is "futureproof" too, in the sense that if a 3rd core kernel package (beyond EDIT: and I just had a realization that the entire point of the |
tonyhutter
force-pushed
the
fedora-kernel-conflict
branch
from
1fbe3d7 to
495bab1
Compare
A user reported that when your upgrade your kernel packages on Fedora with ZFS installed, only the kernel-devel package gets held back to the ZFS-supported version, but not the other kernel packages. So if ZFS only supports the 6.13 kernel, Fedora will still happily upgrade the kernel RPM to 6.14, but hold back kernel-devel at 6.13, for example. This commit includes version checks for the 'kernel-uname-r' dependency, typically provided by the 'kernel-core' package. Closes: openzfs#17265 Original-patch-by: @jkool702 Signed-off-by: Tony Hutter <[email protected]>
tonyhutter
force-pushed
the
fedora-kernel-conflict
branch
from
495bab1 to
8eff9d4
Compare
|
@jkool702 I pushed the |
|
@tonyhutter - it looks good to me, and worked correctly when I tested it. I rebuilt + installed the 2.3.1 zfs-dkms rpm with the kernel-uname-r change and can confirm it gives the desired behavior for Id be happy to give you an official approving review, but I dont have write access for openzfs/zfs. |
|
@jkool702 if you click on the link to the commit in this PR, there's a green "Review changes" button at the top right:
|
There was a problem hiding this comment.
This commit fixes the issue on Fedora where DNF, when a kernel becaome available that wasnt compatible with the current ZFS version, DNF only blocked kernel-devel from installing and allowed the main kernel to still install. This caused many issues, since this kernel couldnt build any kmods (including for zfs) but still tried to, causing partial kernel installs.
With this change implemented, DNF now blocks kernel-devel and the core kernel packages for incompatible kernels from installing. I have tested this on a Fedora 41 install by reompiling the zfs 3.2.1 branch with this change and can confirm that dnf update now works as expected.
A user reported that when your upgrade your kernel packages on Fedora with ZFS installed, only the kernel-devel package gets held back to the ZFS-supported version, but not the other kernel packages. So if ZFS only supports the 6.13 kernel, Fedora will still happily upgrade the kernel RPM to 6.14, but hold back kernel-devel at 6.13, for example. This commit includes version checks for the 'kernel-uname-r' dependency, typically provided by the 'kernel-core' package. Original-patch-by: @jkool702 Reviewed-by: @jkool702 Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tony Hutter <[email protected]> Closes openzfs#17265 Closes openzfs#17271
Motivation and Context
Closes: #17265
Description
A user reported that when your upgrade your kernel packages on Fedora with ZFS installed, only the kernel-devel package gets held back to the ZFS-supported version, but not the other kernel packages. So if ZFS only supports the 6.13 kernel, Fedora will still happily upgrade the kernel RPMs to 6.14, but hold back kernel-devel at 6.13, for example.
This commit includes version checks for the 'kernel' dependency, typically provided by the 'kernel-core' package.
Original-patch-by: @jkool702
How Has This Been Tested?
I tested this on Fedora 41:
dnf updateand verified it only held back kernel-devel, and not the other kernel packages.dnf updateand saw it hold back everything:Types of changes
Checklist:
Signed-off-by.