1

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?

|improve this question
1

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.

|improve this answer
0

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.
|improve this answer
  • 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. – muhammad Sep 26 at 12:54
  • It's "smart" if it works, isn't it? – Jeff Schaller♦ Sep 26 at 13:52
  • 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. – muhammad Sep 26 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 at 15:42
  • 2
    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 at 6:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.