I had a luks volume /dev/sda4 and the filesystem inside it is a btrfs file system. But according to RedHat,

12.1.1. Btrfs has been removed
The Btrfs file system has been removed in Red Hat Enterprise Linux 8. This includes the following components:

The btrfs.ko kernel module
The btrfs-progs package
The snapper package
You can no longer create, mount, or install on Btrfs file systems in Red Hat Enterprise Linux 8. The Anaconda installer and the Kickstart commands no longer support Btrfs.

I tried installing btrfs-progs rpm package as it's not in redhat repo. But it requires lot's of other dependencies which are also not present in RHEL repository and those packages are library packages that has more dependencies.

My current options are,

  1. Downgrading to RHEL 7 which supports btrfs
  2. Boot from a live media and mount the file system, take backup, reformat the partition/block with the filesystem that suppport RHEL 8.
  3. Changing to other linux distribution

I can't choose these options as I am not the decision maker.

So is there any other smart/lazy way of mounting the filesystem?

  • 1
    I would just just pick option 3. :) Feb 12, 2020 at 13:16
  • 1
    "This announcement from Red Hat is purely a reflection of Red Hat's engineering expertise and the way they ship kernels, and not an indictment of Btrfs itself." - news.ycombinator.com/item?id=14907771 . You've been warned. Regarding BTRFS: "Suse uses it as their default and has a lot of inhouse expertise. We use it in a variety of ways inside Facebook. It's getting faster and more stable, admittedly slower than I'd like, but we are getting there.". I would just think about switching to distro that simply has "engineering expertise". Feb 12, 2020 at 13:19

2 Answers 2


It looks like we'll be able to use ELRepo to install kmod-btrfs and btrfs-progs. http://elrepo.org

These packages are currently in the testing repo for EL8 so you might want to wait until they move to the main repo to avoid data integrity issues. I'm sure the ELRepo team would appreciate some extra help testing these packages if you have some time to spare.

  • I don't believe those packages alone will be enough to let you mount a btrfs filesystem. Your kernel also has to support it, and the standard RHEL/CentOS kernels won't, by policy of RedHat. I suspect you will have to install a mainline kernel as well and you would be better off to do that using the kernel-ml package from elrepo than to compile it yourself if you want your system to continue to be 'as enterprise as possible' (automatic, fairly vetted updates) Feb 12, 2020 at 7:09
  • kmod-btrfs was actually in the testing repo but it has been removed. Here's an explanation: mail-archive.com/[email protected]/msg03656.html Apr 19, 2020 at 8:29
  • 1
    Not so sure I'd call that an explanation as much as a shrug and pointing a finger to a miles long ranty forum thread full of conspiracy theories and off topic rants. This continues to smell sour to me. btrfs was plenty stable when el8 was released. I would have been completely happy to have it 'frozen' as Akemi puts it. It's not an internet-exposed attack surface. Frozen is fine. Frozen is what I and most others expect from EL anyway. I'm very disappointed that elrepo removed it rather than pushing to prod. That was the wrong decision. Apr 20, 2020 at 2:19

So is there any other smart/lazy way of mounting the filesystem?

Yes. You need to:

  • compile the Linux kernel from source so that you can add support for BTRFS.
  • compile the BTRFS tools from source and install them.
  • 1
    If you think recompiling kernel or building ‘btrfs’ tools from source is smart/lazy way than the definition of “smart/lazy” in your dictionary is far more different than mine.
    – arif
    Sep 26, 2019 at 12:54
  • It's "smart" if it works, isn't it?
    – Jeff Schaller
    Sep 26, 2019 at 13:52
  • 1
    With due respect, I don't believe every thing that works is smart. If that would be the case than changing to CENTOS/UBUNTU or downgrading to RHEL7 would be much easier than recompiling kernel on RHEL8. As this is enterprise server I just can't do everything that is possible.
    – arif
    Sep 26, 2019 at 15:04
  • You're facing a tough situation: the OS provider has removed support. If you cannot choose another distribution, compiling a btrfs-enabled kernel seems reasonable to me. It's just about as drastic as completely converting the filesystem type through a backup/restore. Perhaps asking for a "lazy" solution to a difficult problem is too much?
    – Jeff Schaller
    Sep 26, 2019 at 15:42
  • 3
    A backup/restore to change the filesystem type is a one-time operation, after which the system should again be in a fully RedHat-supported condition. Compiling a custom kernel would probably mean you (or at least someone) would have to be responsible for recompiling the kernel every time kernel security updates are released, for the expected life of the system, as installing a standard kernel RPM would just remove btrfs support again. And if you need RH support for kernel-level issues in the future, they're likely to first ask: "Is the issue reproducible on a standard RedHat kernel?"
    – telcoM
    Sep 27, 2019 at 6:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .