I'm out, says OpenSUSE: We're dropping bcachefs support from next kernel version
(2025/09/12)
- Reference: 1757680208
- News link: https://www.theregister.co.uk/2025/09/12/opensuse_to_drop_bcachefs_support/
- Source link:
The next kernel will have no new bcachefs code – and the openSUSE versions that use that kernel are going further still.
The maintainers of openSUSE have made a decision over the future of the radical new bcachefs filesystem when openSUSE's distros are concerned: [1]to disable it .
As we [2]discussed in mid-August , the end of the battle between Linux paramount penguin Linus Torvalds and bcachefs boffin Kent Overstreet came to an unhappy conclusion. At the end of August, [3]Torvalds announced that from now on, bcachefs is "externally maintained." As LWN [4]summarized it , this means the new filesystem won't be developed as part of the main Linux kernel tree – but it hasn't been totally removed.
[5]
OpenSUSE, however, is going further: it will elimiate the new filesystem from its kernel builds. Jiří Slabý, who is one of SUSE's kernel maintainers, [6]posted on the project's Factory list :
Given BCacheFS is [7]"externally maintained" since 6.17 , we are [8]disabling the filesystem in 6.17 too. Therefore, everyone using it should follow the BCacheFS' [9]upstream advises how to install/use it.
Anyone interested might also possibly prepare a [10]KMP for themselves (and others).
The current 6.16.* is NOT affected. Neither is Slowroll (for now).
Once the BCacheFS maintainer behaves and the code is maintained upstream again, we will re-enable… (As IMO, it is a useful feature.)
(As an aside, Slabý later expressed regret that his English was too harsh, and [11]apologized downthread . As it happens, this vulture used to work in SUSE in the Czech Republic, although not personally with Mr Slabý, and can attest that the Czech language can seem curt and abrupt when translated directly into English.)
Kernel 6.17 is not out yet – it's still in the release candidate stage; earlier this week, the developers released RC5. But as well as the stable, slow-moving [12]openSUSE Leap , which [13]moves in sync with the enterprise SLE , the openSUSE project maintains two rolling-release distros: the fast-changing [14]openSUSE Tumbleweed and the still-experimental slower-release-cycle [15]openSUSE Slowroll .
[16]
[17]
New kernel versions tend to appear roughly every two to three months, while even the faster-moving fixed-release distros tend to only release twice a year (such as Ubuntu interim releases and Fedora) to every other year (such as Debian). Rolling-release distros, though, continually get a trickle of new program versions as and when they're ready, meaning that they tend to get every kernel version at some point.
Bcachefs hasn't been removed from kernel 6.17: there's just no changes from the version of the code included in the current version 6.16. Something similar happened to version 6.13, as we [18]reported at the end of 2024 : none of Overstreet's changes were incorporated then, as a disciplinary move, and it shipped with the same bcachefs code as the [19]subsequently declared LTS 6.12 . It's too soon to say if the filesystem will be removed from 6.18.
[20]
Bcachefs being externally maintained out of sync with the main kernel doesn't stop anyone using it – it just means it will take a little more work. Being out-of-kernel doesn't prevent millions of machines from running [21]Nvidia's Linux drivers , which are proprietary code and so can't be maintained in-tree.
The most common way is using the [22]Dynamic Kernel Module System (DKMS) , as the [23]Arch wiki explains . DKMS watches for when the OS updates the kernel, and re-links the external code to make loadable modules for the new kernel version. This does work on openSUSE, but the SUSE family has been around for a third of a century, which means it has its own ways of doing things – in this case, its own mechanism called [24]Kernel Module Packages .
Even so, while we can't blame the company for its decision, it's a small blow against bcachefs. In decades gone by, SUSE used to be a proponent of unusual and atypical filesystems. As this [25]2012 story from Linux.com describes, back then the company recommended ReiserFS, XFS, and Oracle's OCFS2.
[26]
Today, SUSE's clever transactional-updates feature depends on its [27]Snapper subsystem, also used in [28]Garuda Linux and [29]rolling Debian variant siduction . Snapper in turn leans heavily on Btrfs (although it does also support [30]thin-provisioned LVM ). SUSE does not support the more mature COW-snapshot-capable [31]OpenZFS , so in an ideal world, we would have liked to see it adopt bcachefs and make Snapper able to use bcachefs as well.
However, it does rather feel to us like recent SUSE products are dropping some of the distro family's familiar features, as we [32]noted looking at the RC of Leap 16 . This drops a number of traditional SUSE tools, such as the YaST system-admin tool and AutoYaST automated installation tool, as well as completely dropping 32-bit binary support and X.org.
[33]GParted: Still the best free partitioner standing – unless you're on a 32-bit box
[34]Public developer spats put bcachefs at risk in Linux
[35]OpenSUSE Leap 16.0 reaches RC status
[36]Garuda Linux 'Talon': Arch, but different. Dare we say it? Better
We are not alone in this, as this [37]recent comment by "DrillShopper" on Hacker News makes plain:
We use SLES15 at work and their bizarre decisions in SLES 16 to remove X servers (except for XWayland), remove 32-bit libraries, and complete removal of their AutoYaST unattended install tool in favor for a tool that is maybe 25 percent compatible with existing AutoYaST files still baffles me. We spent months moving to SLES15 from a RHEL derivative a few years ago and now we basically have to do it again for SLES16 with as big as the changes are. We have some rather strong integrations with the Xorg servers, and Wayland won't cut it for us currently, so we're stuck unless we want to re-architect 20 years of display logic to some paper spec that isn't evenly implemented and when it is, it's buggy as shit.
I've been pushing hard for us to move off SLES as a result, and I do not recommend it to anyone who wants a stable distribution that doesn't fuck over its users for stupid reasons.
We tried not to be quite so forthright, but we do sympathize. We are generally in favor for bold innovation in Linux world, but not to the extent that it removes the very attributes that gave a distro its unique qualities. ®
Get our [38]Tech Resources
[1] https://lwn.net/ml/all/9032de2a-03a7-4f9e-9c8a-8bd81c5d1fc5@suse.cz/
[2] https://www.theregister.com/2025/08/15/sad_end_of_bcachefs/
[3] https://archive.ph/vgstB
[4] https://lwn.net/Articles/1035736/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[6] https://lwn.net/ml/all/9032de2a-03a7-4f9e-9c8a-8bd81c5d1fc5@suse.cz/
[7] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebf2bfec412ad293a0b118fb1a20a551088ebc9b
[8] https://bugzilla.suse.com/show_bug.cgi?id=1248109
[9] https://bcachefs.org/GettingStarted/
[10] https://en.opensuse.org/Kernel_Module_Packages
[11] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/TOXF7FZXDRFPR356WO37DXZLMVVPMVHW/
[12] https://get.opensuse.org/leap/15.6/
[13] https://www.theregister.com/2021/06/04/opensuse_leaps_to_153_now/
[14] https://get.opensuse.org/tumbleweed/
[15] https://en.opensuse.org/Portal:Slowroll
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://www.theregister.com/2024/11/22/bcachefs_linux/
[19] https://www.theregister.com/2024/12/11/linux_612_lts/
[20] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[21] https://www.nvidia.com/en-us/drivers/unix/
[22] https://github.com/dell/dkms
[23] https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support
[24] https://en.opensuse.org/Kernel_Module_Packages
[25] https://www.linux.com/news/suse-linux-says-btrfs-ready-rock/
[26] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[27] http://snapper.io/
[28] https://www.theregister.com/2022/07/28/garuda_linux_arch_better/
[29] https://www.theregister.com/2023/01/05/siduction_2022_1/
[30] https://man7.org/linux/man-pages/man7/lvmthin.7.html
[31] https://openzfs.org/wiki/Main_Page
[32] https://www.theregister.com/2025/08/07/opensuse_leap_16_reaches_rc/
[33] https://www.theregister.com/2025/07/14/gparted_live_1708/
[34] https://www.theregister.com/2024/11/22/bcachefs_linux/
[35] https://www.theregister.com/2025/08/07/opensuse_leap_16_reaches_rc/
[36] https://www.theregister.com/2022/07/28/garuda_linux_arch_better/
[37] https://news.ycombinator.com/item?id=45103571
[38] https://whitepapers.theregister.com/
The maintainers of openSUSE have made a decision over the future of the radical new bcachefs filesystem when openSUSE's distros are concerned: [1]to disable it .
As we [2]discussed in mid-August , the end of the battle between Linux paramount penguin Linus Torvalds and bcachefs boffin Kent Overstreet came to an unhappy conclusion. At the end of August, [3]Torvalds announced that from now on, bcachefs is "externally maintained." As LWN [4]summarized it , this means the new filesystem won't be developed as part of the main Linux kernel tree – but it hasn't been totally removed.
[5]
OpenSUSE, however, is going further: it will elimiate the new filesystem from its kernel builds. Jiří Slabý, who is one of SUSE's kernel maintainers, [6]posted on the project's Factory list :
Given BCacheFS is [7]"externally maintained" since 6.17 , we are [8]disabling the filesystem in 6.17 too. Therefore, everyone using it should follow the BCacheFS' [9]upstream advises how to install/use it.
Anyone interested might also possibly prepare a [10]KMP for themselves (and others).
The current 6.16.* is NOT affected. Neither is Slowroll (for now).
Once the BCacheFS maintainer behaves and the code is maintained upstream again, we will re-enable… (As IMO, it is a useful feature.)
(As an aside, Slabý later expressed regret that his English was too harsh, and [11]apologized downthread . As it happens, this vulture used to work in SUSE in the Czech Republic, although not personally with Mr Slabý, and can attest that the Czech language can seem curt and abrupt when translated directly into English.)
Kernel 6.17 is not out yet – it's still in the release candidate stage; earlier this week, the developers released RC5. But as well as the stable, slow-moving [12]openSUSE Leap , which [13]moves in sync with the enterprise SLE , the openSUSE project maintains two rolling-release distros: the fast-changing [14]openSUSE Tumbleweed and the still-experimental slower-release-cycle [15]openSUSE Slowroll .
[16]
[17]
New kernel versions tend to appear roughly every two to three months, while even the faster-moving fixed-release distros tend to only release twice a year (such as Ubuntu interim releases and Fedora) to every other year (such as Debian). Rolling-release distros, though, continually get a trickle of new program versions as and when they're ready, meaning that they tend to get every kernel version at some point.
Bcachefs hasn't been removed from kernel 6.17: there's just no changes from the version of the code included in the current version 6.16. Something similar happened to version 6.13, as we [18]reported at the end of 2024 : none of Overstreet's changes were incorporated then, as a disciplinary move, and it shipped with the same bcachefs code as the [19]subsequently declared LTS 6.12 . It's too soon to say if the filesystem will be removed from 6.18.
[20]
Bcachefs being externally maintained out of sync with the main kernel doesn't stop anyone using it – it just means it will take a little more work. Being out-of-kernel doesn't prevent millions of machines from running [21]Nvidia's Linux drivers , which are proprietary code and so can't be maintained in-tree.
The most common way is using the [22]Dynamic Kernel Module System (DKMS) , as the [23]Arch wiki explains . DKMS watches for when the OS updates the kernel, and re-links the external code to make loadable modules for the new kernel version. This does work on openSUSE, but the SUSE family has been around for a third of a century, which means it has its own ways of doing things – in this case, its own mechanism called [24]Kernel Module Packages .
Even so, while we can't blame the company for its decision, it's a small blow against bcachefs. In decades gone by, SUSE used to be a proponent of unusual and atypical filesystems. As this [25]2012 story from Linux.com describes, back then the company recommended ReiserFS, XFS, and Oracle's OCFS2.
[26]
Today, SUSE's clever transactional-updates feature depends on its [27]Snapper subsystem, also used in [28]Garuda Linux and [29]rolling Debian variant siduction . Snapper in turn leans heavily on Btrfs (although it does also support [30]thin-provisioned LVM ). SUSE does not support the more mature COW-snapshot-capable [31]OpenZFS , so in an ideal world, we would have liked to see it adopt bcachefs and make Snapper able to use bcachefs as well.
However, it does rather feel to us like recent SUSE products are dropping some of the distro family's familiar features, as we [32]noted looking at the RC of Leap 16 . This drops a number of traditional SUSE tools, such as the YaST system-admin tool and AutoYaST automated installation tool, as well as completely dropping 32-bit binary support and X.org.
[33]GParted: Still the best free partitioner standing – unless you're on a 32-bit box
[34]Public developer spats put bcachefs at risk in Linux
[35]OpenSUSE Leap 16.0 reaches RC status
[36]Garuda Linux 'Talon': Arch, but different. Dare we say it? Better
We are not alone in this, as this [37]recent comment by "DrillShopper" on Hacker News makes plain:
We use SLES15 at work and their bizarre decisions in SLES 16 to remove X servers (except for XWayland), remove 32-bit libraries, and complete removal of their AutoYaST unattended install tool in favor for a tool that is maybe 25 percent compatible with existing AutoYaST files still baffles me. We spent months moving to SLES15 from a RHEL derivative a few years ago and now we basically have to do it again for SLES16 with as big as the changes are. We have some rather strong integrations with the Xorg servers, and Wayland won't cut it for us currently, so we're stuck unless we want to re-architect 20 years of display logic to some paper spec that isn't evenly implemented and when it is, it's buggy as shit.
I've been pushing hard for us to move off SLES as a result, and I do not recommend it to anyone who wants a stable distribution that doesn't fuck over its users for stupid reasons.
We tried not to be quite so forthright, but we do sympathize. We are generally in favor for bold innovation in Linux world, but not to the extent that it removes the very attributes that gave a distro its unique qualities. ®
Get our [38]Tech Resources
[1] https://lwn.net/ml/all/9032de2a-03a7-4f9e-9c8a-8bd81c5d1fc5@suse.cz/
[2] https://www.theregister.com/2025/08/15/sad_end_of_bcachefs/
[3] https://archive.ph/vgstB
[4] https://lwn.net/Articles/1035736/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[6] https://lwn.net/ml/all/9032de2a-03a7-4f9e-9c8a-8bd81c5d1fc5@suse.cz/
[7] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebf2bfec412ad293a0b118fb1a20a551088ebc9b
[8] https://bugzilla.suse.com/show_bug.cgi?id=1248109
[9] https://bcachefs.org/GettingStarted/
[10] https://en.opensuse.org/Kernel_Module_Packages
[11] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/TOXF7FZXDRFPR356WO37DXZLMVVPMVHW/
[12] https://get.opensuse.org/leap/15.6/
[13] https://www.theregister.com/2021/06/04/opensuse_leaps_to_153_now/
[14] https://get.opensuse.org/tumbleweed/
[15] https://en.opensuse.org/Portal:Slowroll
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://www.theregister.com/2024/11/22/bcachefs_linux/
[19] https://www.theregister.com/2024/12/11/linux_612_lts/
[20] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[21] https://www.nvidia.com/en-us/drivers/unix/
[22] https://github.com/dell/dkms
[23] https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support
[24] https://en.opensuse.org/Kernel_Module_Packages
[25] https://www.linux.com/news/suse-linux-says-btrfs-ready-rock/
[26] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aMRDlb6Z1kHBdbAQgqxqUwAAANQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[27] http://snapper.io/
[28] https://www.theregister.com/2022/07/28/garuda_linux_arch_better/
[29] https://www.theregister.com/2023/01/05/siduction_2022_1/
[30] https://man7.org/linux/man-pages/man7/lvmthin.7.html
[31] https://openzfs.org/wiki/Main_Page
[32] https://www.theregister.com/2025/08/07/opensuse_leap_16_reaches_rc/
[33] https://www.theregister.com/2025/07/14/gparted_live_1708/
[34] https://www.theregister.com/2024/11/22/bcachefs_linux/
[35] https://www.theregister.com/2025/08/07/opensuse_leap_16_reaches_rc/
[36] https://www.theregister.com/2022/07/28/garuda_linux_arch_better/
[37] https://news.ycombinator.com/item?id=45103571
[38] https://whitepapers.theregister.com/
There is a slight problem with this
VoiceOfTruth
Whatever the reasoning, (call it kernel politics if you wish), removing something that perhaps many people depend on is a bitter pill you are making them swallow. If it can happen to bcachefs it can happen to something else too. What is the migration path for those who use bcachefs? It's sorry guys, you are on your own.
It also makes the Linux ecosystem less stable. Being able to add it back in manually is not the same thing. bcachefs was touted by some people as a next-gen file system, with fewer problems than btrfs (like it doesn't hose your data if it goes wrong). It is being removed not for technical reasons, not for being a legacy thing which has very little currency. Instead because some people can't get along or don't follow the rules (interpret this how you wish).
If MS or Google said "xyz is being removed from the next version of something", a lot of people would be unhappy if they depend on it. And rightfully so.
m4r35n357
Getting rid of shit because "we can" is quite the fashion these days. Call it "bold & Innovative" if you want; but these people are psychotic.
Of course, if projects had enough "spine" to maintain their individuality, all tastes woud be catered for, but everyone running a project is obsessed with numbers, so it is a race to the bottom, tending towards zero choice.
If you really want to keep stuff, perhaps a less up to date distro is the answer. I am pursuing that course for now.
Ian Johnston
What sort of bloated monstrosity of an OS incorporates file system support in the kernel anyway?
Possibly not a bad thing actually. Presumably having bcachefs enabled in the kernel wouldn't play nice with trying to use the more up-to-date out-of-tree version.