Bcachefs Transitioning to DKMS Packaging: What Users Need to Know

Bcachefs moves from in-kernel delivery to DKMS modules. Here’s how it impacts Debian, Arch, Fedora, and openSUSE users.

Bcachefs has been one of the most talked-about names tied to nearly every Linux kernel release in recent months, with the drama around it showing no signs of slowing down.

The clash between the file system’s lead developer, Kent Overstreet, and Linus Torvald’s finally came to a head, resulting in Bcachefs being pulled from the still-in-development Linux kernel 6.17. And now, there’s yet another twist in the story.

In a message to the kernel’s mailing list, Overstreet announced that the project is moving away from being shipped directly in the kernel and will instead be provided as a DKMS module.

For our less tech-savvy readers, DKMS (Dynamic Kernel Module Support) is a system that makes sure extra kernel modules—like Bcachefs—keep working whenever your Linux kernel updates.

Normally, if a driver or filesystem is built directly into the kernel, it comes bundled with it. But if it’s provided separately, it could break every time the kernel changes. DKMS solves this by automatically rebuilding the module against the new kernel during updates, so users don’t have to recompile things manually.

This transition won’t significantly affect everyday users, since DKMS modules can be bundled in initramfs just like kernel modules, allowing root filesystems to function normally. However, distribution maintainers will need to adjust packaging workflows to ensure the process runs smoothly across different environments.

Until now, many users have installed Bcachefs from their distribution’s stock kernel. With the switch to DKMS, distros such as Debian, Fedora, Arch, and openSUSE will need to coordinate packaging and testing. The community has already begun stepping up to support this effort.

Moreover, Overstreet emphasized that quality assurance and stability remain top priorities. He noted that Bcachefs 6.16 has proven to be a strong release, with no new critical bugs reported. Most recent fixes have targeted performance or testing issues rather than user-facing failures. This stability puts the filesystem closer to dropping its “experimental” label.

At the same time, one of the major hurdles is ensuring userspace tools keep pace. Historically, up-to-date bcachefs-tools packages haven’t been essential, since the kernel offered fallback mechanisms. But with DKMS, distributions will need to maintain these packages more actively.

  • Fedora maintains a Bcachefs tools package, while openSUSE (which was quick to announce that they were removing it from its 6.17 kernel) will likely need extra attention to integrate DKMS properly.
  • On Debian, the tools package was orphaned and eventually removed, but work is underway to bring it back via the experimental branch.
  • Arch Linux and NixOS already collaborate closely with upstream and have contributed to recent DKMS support.

Overstreet asked for additional testers and experienced packagers to help refine the new workflow, noting that while development has been intense, the critical debugging phase is slowing down, and the project now has more bandwidth to focus on distribution support.

In short, for end users, the short-term picture remains stable. Most will continue running the solid 6.16 release even as 6.17 arrives, buying distributions time to adapt their packaging. The move to DKMS is expected to smooth out long-term support and make Bcachefs more flexible across different kernels.

In the end, the hope is that the differences between Overstreet and Torvalds can eventually be resolved, allowing for more effective collaboration. Bcachefs brings strong technical qualities that could position it as a leading file system for Linux, and keeping it out of the default kernel feels like a real loss for the community.

Bobby Borisov

Bobby Borisov

Bobby, an editor-in-chief at Linuxiac, is a Linux professional with over 20 years of experience. With a strong focus on Linux and open-source software, he has worked as a Senior Linux System Administrator, Software Developer, and DevOps Engineer for small and large multinational companies.

Leave a Reply

Your email address will not be published. Required fields are marked *