fix: block incompatible kernel from being installed #16139
Conversation
The current "Requires" lines only ensure the old kernel is available on the system but it does not prevent fedora from updating to an incompatible and breaking user's system. Set Conflicts to block incompatible kernels from being installed. Signed-off-by: tleydxdy <shironeko.github@tesaguri.club>
|
From my recollection of the last time this was discussed, since the kernel packages are considered special/required, this just results in dnf resolving the conflict by uninstalling the ZFS packages. |
|
Interesting, I must have missed that discussion. I tried to search and read-up on this issue :( |
|
Is #15188 what you are referring to? I think it is useful to spell-out what is the expected way to consume zfs-dkms on ""rolling"" distros where kernel upgrades to incompatible versions on a routine bases. Below is what I gathered reading various issues. The current situation:
The ideal in my opinion:
My understanding is with conflict and setting zfs as protected, it achieves this goal with the caveat that dnf will print a warning when upgrading. is that correct? |
|
My (personal, not any kind of larger group or org) general advice is not to use it on a rolling distro that bumps kernel revs, really, precisely because it's going to break like this. I don't actually know if that was the discussion, it's come up a few times, but my understanding is that there's not really a good way to express what's wanted in I guess you might be able to do something weird like a postscript or conf file that adds a hold or analogue on the kernel range that's acceptable, maybe? |
|
I'm fairly sure protected is the way to handle it, here's from dnf docs:
I do agree with the points made in the other issue thread though. I don't think setting zfs protected should be done automatically by the package install script if only for the reason that it blocks user uninstall also. So I think a sentence should be added to the fedora install guide to tell user why they need to set this. |
|
I don't really agree with setting it either, though, is the thing, I think. That's just going to provoke lots of angry messages about how it broke their upgrade process entirely, and half of them followed by they undid it and it broke, IMO. That's not really a better experience, because it's more frustration, and still broken at the end with what they're likely to do without looking up what they should do. Much as I like to encourage people to read documentation, the reality is that people aren't going to go check it if something breaks, they're going to do what seems to make sense to them to get past this complaint, and that's going to break them the same way as before, but with even higher frustration b/c they've spent more time on it. |
|
I'm not sure that is the case? Currently the situation is broken for both people that follow instructions and people that do not, and with this change it makes it so people that follow the instructions can have a better experience and people that don't is not worse off anyway. right? |
|
My argument is that people who follow instructions, it will still be broken the same way, because the ideal outcome is that it upgrades everything else possible but stops the kernel from upgrading past the allowed version, right? If you mark the ZFS packages as protected, if I understand the behavior right, it'll refuse to upgrade if there would be a conflict that would require removing one of (kernel|zfs), and if they unprotect it, it'll break just like if they had never done that dance, yes? (To say nothing of if you unprotect the kernel packages, which I'm not sure it'll even allow you to do...) And if you don't, it'll break the same way it currently does. So my claim is based on the idea that "break all upgrades" is not a net gain, because people are just going to end up at the same end state, plus some frustration to undo the thing that stopped them doing the upgrade in the first place, and there's not really any outcome they can have from that state other than "wait for a newer version to make that not a problem" that's better. If I'm misunderstanding something here, or you disagree with my conclusions, I'd love to hear how I'm wrong or not viewing this the same way - I don't have a particularly strong opinion on this, just that if I understand the situation right, this would just break the "rolling" in "rolling upgrades" entirely if the situation comes up, which I claim is just going to result in more frustration and people still breaking their systems, absent a better solution. |
|
Do you know how I can download the build artifact from buildbot? It might be valuable to have some practical examples. |
Motivation and Context
The current "Requires" lines only ensure the old kernel is available on the system but it does not prevent fedora from updating to an incompatible and breaking user's system.
Description
Set Conflicts to block incompatible kernels from being installed.
How Has This Been Tested?
Waiting for build test
Types of changes
Checklist:
Signed-off-by.