Kernel 6.4 incompatibilty #15258
Comments
|
👍 Greetings from Australia |
I don't think so... Actually those people working hard on OpenZFS are the best people in the world. Delivering the best filesystem for free. They are also great educators, because from videos published on YouTube I've learnt a lot about the architecture of ZFS itself, learning a lot of great ideas I use in my other projects. So no, they are definitely not criminals :-)
Oh, so this is you who made a mistake, not OpenZFS team
So this is your solution which doesn't work. OpenZFS clearly declares which kernels it is compatible to.
The trap you created...
I agree, the system you created to manage your OS is very shitty
No, this is YOU who destroyed YOUR property
Exactly, you do it again and again. And every time you do it, you share your frustration here.
I guess it's possible once you donate an appropriate sum to the team. Why anyone else should pay for fixing the mess you created?
Good for you (and us)! (maybe someone should warn the btrfs team) |
|
I'm not a Fedora user, but it took me one minute to figure out a solution: Simple web search led to this: Otherwise, not much to say other than which was already said here: |
|
@tonyhutter I could agree with one thing, not really mentioned by @Moerten. You could improve communication by sharing ETAs for the next version. I guess there is a good reason why 2.2.0 is still a release candidate and why 2.1.x is not upgraded to support new kernels. But at the same time it would be nice to simply tell us how the roadmap looks like. |
|
I found a more easy solution in the meanwhile to install the apropiate headers now. One can simply add to file "/ect/dnf/dnf.conf": But this takes all time to find out maybe installing the whole system from scratch multiple times. |
|
(I want to be clear that while it says "member", I speak for nobody but myself, I'm just marked that way so I can do random nonsense like add type tags on issues.) If OpenZFS's packages on Fedora blocked upgrading the kernel, then there'd be even more issues objecting to that, and since RH sometimes backports wild things into their kernel trees, to say nothing of Linux upstream itself sometimes doing it, it still wouldn't stop things breaking. My personal advice has been, for some time, that you should likely not run OpenZFS on a fast-moving distro that ships breaking kernel updates regularly, like Arch without using one of the special repos I believe exists to allow you to pin a kernel version that's known to work with the OpenZFS packages, or Fedora. There's only so much time in the day, for anyone, and anecdotally, though I haven't conducted a poll, a lot of the people paid to work on OpenZFS at their day jobs don't ship brand new kernels, so supporting the latest kernel is left to the available time that isn't on work priorities for them or people who aren't getting paid to do it. Since I think an outright block on updating your kernel on Fedora or the like would be a nonstarter for multiple reasons, we could, conceivably, make it print a warning in the RPM packages on first install suggesting people consider pinning their kernel lest this happen (maybe? I know debs have a thing for this, but I don't recall if I've ever seen an RPM do it...), but I think that's as far as we can go - given that the kernel is a critical package, I think it'd just eject the ZFS packages unless you held them no matter how we marked them otherwise, and probably scream murder if it wanted to upgrade the kernel but that stopped it without an explicit hold on the kernel (and, as I said above, I don't think that would even prevent all or possibly even most breakages, with how much Linux upstream seems to like breaking changes). So, I'm not sure what to suggest here. You're free to contribute or work on other people contributing faster kernel update support, though the other tradeoff with that being faster is that you'll more often encounter surprises with cases that might not have been discovered in testing (for example, right now, there's one on 6.3+ with native encryption and the memory rework that panics the kernel if it tries to compact RAM), or if there's some panacea I've overlooked because I'm as fallible as the next person, that'd be great too. My final remark would be that we do, in fact, have a code of conduct around here, so while I understand you're quite frustrated, please try to be mindful of others in your replies. |
|
Ubuntu has official ZFS support in their distribution, it just frozen at a particular version (I think it’s 2.1.9 in 22.04 LTS but don’t quote me on that). I would recommend using Ubuntu if you’re not prepared to deal with issues like the one you are dealing with. Ubuntu also has a nice LiveCD. Assuming you don’t have any ZFS features enabled that break support with that ZFS version, you ought to be able to access your pool using the Ubuntu LiveCD. The problem OpenZFS suffers from is that it is an out-of-tree filesystem and the Linux kernel is a fast-moving target, stuff breaks in new kernels all the time unfortunately. I would highly suggest switching to a distro that has an LTS kernel. I’m not a Fedora user. I would suggest either Ubuntu or RHEL / RHEL clone with an LTS kernel. Just my $.02, I don’t speak for the project, just a user of ZFS for many years. |
|
It's a one-liner to configure your system to only update the kernel to a version compatible with the latest zfs version. If that is too much of a demand, then free software is not for you. I find this attitude rigorously annoying. |
Add optional step to configure Fedora to never remove zfs, even if it means keeping an older kernel openzfs/zfs#15258
I've also suggested in openzfs/openzfs-docs#453 that the Fedora-specific documentation calls out this issue, and provides an optional step to prevent it occurring, as well as setting out the consequences. |
Add optional step to configure Fedora to never remove zfs, even if it means keeping an older kernel openzfs/zfs#15258
|
@Moerten can you post the error you were seeing? I'm able to install zfs-2.1.12 packages on F38 with the 6.4.14 kernel: |
|
How did you manage that ? My current FC38 will not update with out removing zfs (I've done |
|
And more specifically : |
My setup was:
I just wanted to confirm that zfs 2.1.12 could build against the F38 6.4.14 kernel, since #15258 (comment) was indicating that it wasn't working. |
|
This is a physical machine, so maybe the kernel packages differ ? Apparently ZFS 2.2 is nearly ready, which should hopefully resolve ? https://www.theregister.com/2023/08/16/openzfs_zfsbootmenu_2_2/ |
It seems related to the dependency on kernel-devel 6.2.9-300.fc38. Booting into the new kernel and reinstalling zfs and zfs-dkms packages reinstalls kernel-devel 6.2.9-300.fc38 but DKMS appears to happily build for the running kernel: |
|
I don't fully understand. So |
|
I know almost nothing of the dark arts of rpm package management, however a quick look shows at a guess the zfs package pulls in zfs-dkms as a dependency which itself then pulls in kernel-devel <= 6.2.99 as a dependency. I dont know what the impact of building the kernel modules against a later kernel-devel version is, and do not personally use Fedora in production (I use it for testing different softwares compatibility against more recent library/kernel versions and dont care if the box blows up). |
Ok, so maybe there's a bug/feature that zfs-dkms just always builds against the current kernel no matter what the Note that zfs-2.1.13 with 6.5 kernel support is currently going though review (#15268). |
Yeah, but you should warn people that encryption is broken on >6.3 kernel, seems that another user lost their dataset while using on 6.5.2 here #15275 I wanted to test if it's gotten better on recent commits, but I'm not gonna risk it now unfortunately. My root pool is encrypted. |
That user is using HEAD of master, which is version 2.2.x. There a lot of huge changes have been introduced. 2.1.13 is mainly fixes. |
I didn't know that encryption had issues even on older kernel, I'll probably turn it off then at this point. My two cents on this is that it should be at least mentioned in the release notes on the stable version, IMHO, since it claims 5.3 compat. (Yeah, #15140 is an issue opened by me :)) |
Unfortunately quite a bunch of problems with encryption: More unfortunately it doesn't look like they get addressed. |
|
Oh, that's not funny. I guess I'm not the only one storing the most important data on encrypted dataset |
If you have lost some data that means: no backup of it was done. To quote your own word: not having backup of critical data is unacceptable. Nothing in this world is perfect and people around here are at hard work on various aspects (fixing bugs, testing, documenting and so on) and you get their work for free. Even commercial software agreements (unless you deal with very special circumstances) write this in capitals: software is provided as-is with no warranty and the vendor declines any kind of responsibility (damage, profit lost, ...). Look, things can and will fail at some point, sometimes even for the dumbest possible reasons. If you are not sure about how things will end, testing in a breakable environment is far from being forbidden. At the end, you are responsible of the usage of a piece of software, not the community who works on a best effort principle. If you had taken the time to go through a couple a bugs reports, you would have seen that ZFS encryption has some issues then make your opinion to use it or not. Great news for you: like many things in life, you are not entitled to anything here. Even paying for a support contract would not mean seeing an issue being automagically fixed and getting your data back. If what you are telling us is the truth and not something emphasized under frustration / anger, loosing data several times and not being able to take and restore a backup of it and not testing stuff before putting in production is a serious issue. If you do not learn the lesson and loose your data over and over again without taking counter-measures for that... well... too bad to sad. I can not even sympathize with you, to speak for myself. Assuming responsibilities is one the basic attitudes. Read: your data, your responsibility, your problem. Full-stop. Next time, open a bug report and work in collaboration with the community rather than whine pointlessly on it. This will be more constructive and useful. Being respectful and thankful for the work done by the community are not optional. |
|
I don't believe there are extensive encryption issues. A quick read shows either very old (>3y), not using a ZFS release (eg -git), doing unusual things (shared folder with Windows) and so forth |
Well, the stable release claim 6.3, but it's kinda broken, see above with hugepages issues. Haven't looked at all the rest though. It's not as bad as others said, though, IMO. |
Bugs are still bugs if they never get fixed. Several of the bugs predate OpenZFS merging native encryption into mainline git, and still exist. |
sadly "btfs" breaks even if its untouched zfs at least it only breaks when kernel updates are done :D I just wish zfs would unmount correctly when I do a suspend during power failures every time I |
and others
I allowed to open a new issue, due to you are ignoring existing ones since weeks.
ZFS isn't compatible to actual linux kernels since months now.
Now I accidentally updated my Fedora 38 system getting kernel 6.4 installed. No problem I thought.
Because your shitty ZFS broke my system dozen of times within the last years I found a solution to use "grubby" to boot into an older kernel. But because your ZFS is completely outdated there wasn't a 6.3 kernel installed anymore. And now I am stuck in a trapp. I couln't find a way to install an older kernel with apropriate kernel headers and thus it is impossible to access my data.
It is also impossible to set up a newly installed system as there are existing kernel-headers 6.4 only.
At least I know no solution to get a <= 6.3 kernel with headers installed.
This behaviour in completely inacceptable.
YOU ARE DESTROYING OTHER PEOPLE'S PROPERTY. So I will call you criminals.
And you do it again and again and again. It's a shame. And you even don't care for the problems you cause.
I expect to be released a compatible ZFS version or a solution to access my data gain. ASAP!
Luckily I need new drives soon. I will migrate to btrfs then. Only have a look at the last two dozen issue requests. Your code base must be completely broken.
The text was updated successfully, but these errors were encountered: