Support Fedora 42

[tonyhutter]

Describe the feature would like to see added to OpenZFS

Placeholder issue to support Fedora 42 for when it comes out April 15 2025.

How will this feature improve OpenZFS?

Additional context

We can't really do anything until Fedora releases their cloud images for our CI to use:
https://download.fedoraproject.org/pub/fedora/linux/releases/42/cloud/images

[tonyhutter]

Looks like F42 is giving us some compiler errors:

   CC       module/zcommon/libzfs_la-zfs_fletcher_superscalar.lo
    CC       module/zcommon/libzfs_la-zfs_fletcher_superscalar4.lo
    CC       module/zcommon/libzfs_la-zfs_namecheck.lo
    CC       module/zcommon/libzfs_la-zfs_prop.lo
    CC       module/zcommon/libzfs_la-zfs_valstr.lo
    CC       module/zcommon/libzfs_la-zpool_prop.lo
  module/zcommon/zfs_valstr.c:190:16: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (3 chars into 2 available) [-Werror=unterminated-string-initialization]
    190 |         { '.', "DA", "DONT_AGGREGATE" },
        |                ^~~~
  module/zcommon/zfs_valstr.c:154:59: note: in definition of macro '_VALSTR_BITFIELD_IMPL'
    154 | static const valstr_bit_t valstr_ ## name ## _table[] = { __VA_ARGS__ };\
        |                                                           ^~~~~~~~~~~
  module/zcommon/zfs_valstr.c:191:16: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (3 chars into 2 available) [-Werror=unterminated-string-initialization]
    191 |         { '.', "RP", "IO_REPAIR" },
        |                ^~~~
  module/zcommon/zfs_valstr.c:154:59: note: in definition of macro '_VALSTR_BITFIELD_IMPL'
    154 | static const valstr_bit_t valstr_ ## name ## _table[] = { __VA_ARGS__ };\
        |                                                           ^~~~~~~~~~~
  module/zcommon/zfs_valstr.c:192:16: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (3 chars into 2 available) [-Werror=unterminated-string-initialization]
    192 |         { '.', "SH", "SELF_HEAL" },
        |                ^~~~
  module/zcommon/zfs_valstr.c:154:59: note: in definition of macro '_VALSTR_BITFIELD_IMPL'
    154 | static const valstr_bit_t valstr_ ## name ## _table[] = { __VA_ARGS__ };\
        |                                                           ^~~~~~~~~~~
  module/zcommon/zfs_valstr.c:193:16: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (3 chars into 2 available) [-Werror=unterminated-string-initialization]
    193 |         { '.', "RS", "RESILVER" },
        |                ^~~~
...

[tonyhutter]

This makes it build again, I'll put together a PR:

diff --git a/cmd/zpool/os/linux/zpool_vdev_os.c b/cmd/zpool/os/linux/zpool_vdev_os.c
index 8da9aece4..36f0e46e7 100644
--- a/cmd/zpool/os/linux/zpool_vdev_os.c
+++ b/cmd/zpool/os/linux/zpool_vdev_os.c
@@ -88,7 +88,7 @@
 
 typedef struct vdev_disk_db_entry
 {
-       char id[24];
+       char id[24]     __attribute__ ((nonstring));
        int sector_size;
 } vdev_disk_db_entry_t;
 
diff --git a/module/zcommon/zfs_valstr.c b/module/zcommon/zfs_valstr.c
index 546de63c8..e8ea6a294 100644
--- a/module/zcommon/zfs_valstr.c
+++ b/module/zcommon/zfs_valstr.c
@@ -39,7 +39,7 @@
  */
 typedef struct {
        const char      vb_bit;
-       const char      vb_pair[2];
+       const char      vb_pair[2]       __attribute__ ((nonstring));
        const char      *vb_name;
 } valstr_bit_t;
 
diff --git a/tests/zfs-tests/cmd/file/largest_file.c b/tests/zfs-tests/cmd/file/largest_file.c
index 82b795601..a876d8327 100644
--- a/tests/zfs-tests/cmd/file/largest_file.c
+++ b/tests/zfs-tests/cmd/file/largest_file.c
@@ -62,7 +62,7 @@ main(int argc, char **argv)
        offset_t        llseek_ret = 0;
        int             write_ret = 0;
        int             err = 0;
-       char            mybuf[5] = "aaaa\0";
+       char            mybuf[5] = "aaaa";
        char            *testfile;
        mode_t          mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;
        struct sigaction sa;

[no-usernames-left]

We can't really do anything until Fedora releases their cloud images for our CI to use:
https://download.fedoraproject.org/pub/fedora/linux/releases/42/cloud/images

Missing arch, and Cloud not cloud:
https://ftp.halifax.rwth-aachen.de/fedora/linux/releases/42/Cloud/x86_64/images/

[no-usernames-left]

A bigger wrench in the works: Fedora 42 ships with kernel 6.14 and ZFS 2.3.1 supports only up to 6.13:

Linux localhost-live 6.14.0-63.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Mar 24 19:53:37 UTC 2025 x86_64 GNU/Linux

[no-usernames-left]

@tonyhutter How is this completed (=F42 supported) when F42 ships with 6.14 which is not supported by ZFS 2.3.1?

[tonyhutter]

@no-usernames-left it got closed when 155847c was merged. I just re-opened the issue though.

We'll support Fedora 42 in our upcoming 2.3.2 release (#17214) which builds under the 6.14 kernel.

Also related: #17249

[no-usernames-left]

Thank you for all your hard work!

[jkool702]

@tonyhutter - If you want me to create a separate issue for this I will, but the changes to how DNF dependencies work in Fedora in the 2.3 release are awful and (on my system at least) arent doing what you had intended them to do.

I dont remember the exact issue, but shortly before the 2.3 release there was a comment chain about what the changes to DNF dependencies in the 2.3 release was supposed to accomplish. From what I recall, it was basically supposed to make DNF stop installing kernels at the last officially supported kernel but otherwise remain fully functional.

It would be great if it actually did this, but it doesnt (not on my system at least). What it does is make DNF stop installing kernel-devel at the last officially supported kernel but otherwise remain fully functional. Meaning it will still happily install the kernel / kernel-core / kernel-modules / all the rest of the kernel packages EXCEPT for kernel-devel for unsupported kernels. Which DNF does without so much as giving you a warning. everything appears to be going well when all of a sudden the kernel postinst script that builds the zfs modules for the new kernel fails (since, surprise, it silently decided it wasnt going to install the updated kernel-devel package), which makes the whole postinstall error out and leaves you with out one of your old working kernels and with a partially-installed, not fully setup new kernel that is probably set to be used as the default boot kernel and that you CANT build the zfs modules for since DNF will straight refuse to install the kernel-devel package alongside a not-officially-compatible zfs package version.

If you use ZFS on root, at this point you either have another compatible kernel (beyond the one DNF just removed) or you rebuild the zfs package using a modified spec file that doesnt prevent you from installing kernel-devel.

And to make matters worse, this "unexpectedly dropping you in a terrible situation that isnt easily fixable without warning or any indication that something isnt right" behavior is virtually guaranteed to happen every few months, since the zfs release that supports a new kernel almost always lags Fedora first using that kernel by at least a couple of weeks. Which is completely understandable, but also pretty much means you get to go through this before every new zfs 2.3.x release.

<\rant>

Seriously though, its pretty bad (assuming it is working this way for everyone on Fedora, not just me). I have to believe this is actively preventing most/all "casual" users from using ZFs on Fedora...

The fix seems easy enough at least though....in the spec file repeat the existing kernel-devel dependencies for all the various kernel packages.

[tonyhutter]

@jkool702 thanks for reporting this, and I'm sorry you are hitting this issue. I think your theoredical fix is correct that we need to hold back all the kernel-* packages. I've created an issue so we can track it: #17265

[WillJDunn]

@jkool702

Which is completely understandable, but also pretty much means you get to go through this before every new zfs 2.3.x release.

As a workaround for now:
You can avoid this by manually excluding the kernel from DNF as described in the OpenZFS guide for getting started on Fedora (see step 7), then updating the kernel only when the new version is supported by ZFS. I suspect that's why this issue hasn't been widely reported, Fedora users have grown accustomed to the workaround.

You can either exclude the kernel via the --exclude command line option during each execution of dnf update:

dnf update --exclude=kernel*

Or append it to the [main] section of /etc/dnf/dnf.conf and have it automatically excluded from all dnf commands:

[main]
exclude=kernel*

You can exclude specific kernel versions, which allows updates of minor updates of the current kernel while avoiding update to an incompatible kernel:

dnf update --exclude=kernel*6.13*,kernel*6.14*,kernel*6.15*

When you update to a new version of ZFS, you can adjust your dnf exclude to allow upgrading to the new compatible kernel.

I have to believe this is actively preventing most/all "casual" users from using ZFs on Fedora...

This workaround is definitely inconvenient, basically requiring the micromanagement of kernel updates.

postinstall error[s] out and leaves you with out one of your old working kernels

Depending on the size of your boot partition, you may be able to increase the number of kernels that are preserved by adding "installonly_limit={number of desired kernels}" to the [main] section of /etc/dnf/dnf.conf. Though setting this value too high can cause your boot partition to run out of space, the default value of 3 is quite low.

[ftc2]

@tonyhutter

@jkool702 thanks for reporting this, and I'm sorry you are hitting this issue. I think your theoredical fix is correct that we need to hold back all the kernel-* packages. I've created an issue so we can track it: #17265

this is great, and i look forward to the day that i can just sudo dnf upgrade without paying attention. for some reason i assumed that this was impossible for some technical reason, but if the dnf system can be leveraged to Just Work™, wow.

however, in the meantime, i opened an issue about improving the docs to teach users how to prevent this from happening and how to recover if it does happen: openzfs/openzfs-docs#542

[jkool702]

@WillJDunn - I appreciate the info. Ive actually been using dnf update -x kernel\* on and off (as needed) for a good bit of time.

To be honest, the "rant" really wasnt intended as "I dont know what to do and am frustrated". To give perspective, my Fedora system is setup (for 5+ years now) to use zfs on luks on root, to do grub-less booting by directly booting UKI's from my UEFI, and uses secure boot exclusively with personal self-signed x509 keys. Figuring that all out from scratch involved learning how to fix my system from far worse than a half installed kernel lol.

But I imagine this makes me the exception, not the rule. Hense, the "rant" was more "Fedora and ZFS are 2 of my absolute favorite projects in the Linux space and its frustrating that a bunch of people's only experience combining these two awesome things might be 'I tried combining them and DNF broke everything'".

Side note: by far the easiest way to fix things ive found is, after you get ZFS updated and the required kernel-devel installed, just run dnf reinstall kernel\*. Seems to do a great job of fixing everything and is super easy.

[tonyhutter]

ZFS 2.3.2 has been release with Fedora 42 support. This includes correctly holding back kernel upgrades (81dec43) so an incompatible kernel doesn't get installed.

[PACordonnier]

Hey, thanks I was able to install the package zfs-release for fedora 42.

However I cant install anything ZFS as 42 is not available yet on http://download.zfsonlinux.org/fedora/ (YUM repos installed by zfs-release)

I'm wondering what is missing for it to be available. Could it simply be an oversight?

[tonyhutter]

@PACordonnier the RPMs are there (for example: http://download.zfsonlinux.org/fedora/42/x86_64/zfs-2.3.2-1.fc42.x86_64.rpm), but I suspect the index.html files for the webpage needs to be refreshed. I'll do that today.

You should still be able to install on Fedora 42 as per our instructions (make sure you are using zfs-release-2-8 for Fedora 42):

dnf install -y https://zfsonlinux.org/fedora/zfs-release-2-8$(rpm --eval "%{dist}").noarch.rpm
dnf install zfs

https://openzfs.github.io/openzfs-docs/Getting%20Started/Fedora/index.html

[tonyhutter]

@PACordonnier website refreshed with Fedora 42 indexes: http://download.zfsonlinux.org/fedora/42

[no-usernames-left]

To be honest, the "rant" really wasnt intended as "I dont know what to do and am frustrated". To give perspective, my Fedora system is setup (for 5+ years now) to use zfs on luks on root, to do grub-less booting by directly booting UKI's from my UEFI, and uses secure boot exclusively with personal self-signed x509 keys. Figuring that all out from scratch involved learning how to fix my system from far worse than a half installed kernel lol.

But I imagine this makes me the exception, not the rule. Hense, the "rant" was more "Fedora and ZFS are 2 of my absolute favorite projects in the Linux space and its frustrating that a bunch of people's only experience combining these two awesome things might be 'I tried combining them and DNF broke everything'".

Very eloquently put. (And I agree, too!)

[PACordonnier]

perfect @tonyhutter, I had to manually enable the repo (dnf is not being cooperative to enable ZFS repo for some reasons) but was able to install zfs on fedora 42, thank you for your work !