How to convert root fs to btrfs?

Ask Fedora
,
1

I have found a number of old articles on converting to btrfs, several for converting root, but all for other distributions that reference non-fedora things, like not using dracut to rebuild initrd images. I’ve tried several times to convert my VM root disk from ext4 to btrfs, and it all makes sense, but boot stalls and graphical login never arrives. It says “reached multi user target” and many services fail, including DBUG not being able to start on readonly media, then nothing. Virtual consoles never start. Also I cannot boot to single mode, never get root password prompt.

None of this makes any sense. How is rescue mode not working?

Does anyone know of a fedora-focused btrfs conversion cookbook?

Better yet, does anyone know what conditions are required? If I just knew what conditions were necessary I could figure out what to change and how.

  • boot install/rescue media – sure, because convert cannot be done on mounted fs.
  • convert filesystem with btrfs-convert – obviously required
  • update fstab with new UUID & fstyp – makes sense, required
  • update grub config (from chroot env) – it is not clear why this is necessary; grub config looks the same to me after doing this. Perhaps this is the problem, but since I don’t know what is supposed to change, I cannot fix it. kernel boot params don’t include root fs type, so…
  • (?)rebuild initrd images – it is not clear if or why this is needed, either. Is btrfs not part of initrd img? If not, just rebuilding it will not help anyway, dracut needs to be told to add btrfs, right?
  • something else, the above is insufficient.
3 Likes
2

Hello @pdestefa On https://fedoraproject.org/wiki/Btrfs is a start of some answers to your questions.
You know Fedora 33 is shipped with btrfs ?

1 Like
3

Hi @pdestefa,
bit of a shot in the dark, but to me this sounds like things not being mounted in the right places

What is your current partition/filesystem layout, are you using LVM and do you have any spare space on your disk to move stuff around in?

Prior to Fedora 33, btrfs support is compiled as a loadable module, not part of the kernel, so it needs to be pulled into the initrd. I don’t know exactly how dracut does things, but I assume it adds the module when it is run from a root btrfs filesystem.

4

@jpbn, yes, I had read that page before. I don’t see any thing I missed, it’s not so detailed as to layout the core requirements for booting off btrfs. Also, the whole reason I’m trying to do this is the switch to btrfs in F33. I will upgrade when it releases and I want to maintain parity with the fedora base.

The installation section says that two subvolumes are created for root & home. So, perhaps that is something I’m not doing correctly in my conversion. But, again, it is not clear why that is needed. I was able to mount the filesystem without subvolume selection, manually, so I don’t see why or how that aspect is related to the boot process.

5

@lcts & @jpbn, thanks for your help!

@lcts, I do have LVM that I created at install time. Lay out is one virtual disk w/ two partitions, one for /boot and one for PV. In LVM is root & home LVs. I believe this is the default layout from F30-ish if you choose LVM.

Ah, okay, well, that means I need to tell dracut to add btrfs support. That, at least, is a logical interpretation of the symptoms I have. I just wish I had seen a boot log error about not being able to mount fs because fs was unknown or something. But, without access to rescue, it cannot review the boot log in full. So, we have to guess. Thanks. At least that is something I can try differently next time.

If anyone comes across a Fedora-specific walk through or requirements list, please post here.

6

Here is another concern I have: grub2-mkconfig is producing “root=/dev/mapper/fedora-root” option. Should this be UUID based? And, if so, could that be related to this boot problem? Using /dev seems safer, since UUID of the fs changes during the conversion to btrfs. So, I can see that kernel params would need to be changed if root was specified by UUID; but, it’s not.

Now, I noticed that my VM doesn’t include all the kernel options that my other system includes. For example, my main system includes ‘rootfstype’ option. Think that would help?

1 Like
7

@jpbn, I had another thought about your comment. If I wait until after upgrading to F33, I might not have to trick dracut into including btrfs support into initramfs. Is that what you were suggesting? If that interpretation is accurate, then that might be the best way to go.

8

@pdestefa The page has a lot of links to other sources of knowledge. It is good to learn about btrsf. Just go on and try.

About F33, it is available now. I do use it for most of my computer needs. You could try that and see if that works for you.

9

ext4 on LVM is not going to go away in F33, it will probably be supported forever, just the default layout for new installations will change. Just like the other way around, btrfs has been there, it just wasn’t the default.

The sys-upgrade path won’t be broken for F32 systems on ext4/LVM, just keep upgrading as before.

I wouldn’t worry too much about misalignment with Fedora “base”. And if you do, do a clean install of F33, that’s more efficient than that fs conversion.

10

Then converting the FS via btrfs-convert does not make much sense, you’ll end up with btrfs filesystems on top of LVM logical volumes, which negates a big part of what switching to btrfs is trying to achieve (flexible volume/partition sizes).

I agree with @florian, if you want to try out btrfs, do it from a fresh install, otherwise, LVM+ext4 will continue to be fully supported for the forseeable future.

2 Likes
11

Blockquote
The page has a lot of links to other sources of knowledge. It is good to learn about btrsf. Just go on and try.

I read several of the the kernel.org wiki pages and no where is it described what is required to boot off btrfs. I interpret this to mean that it is no different than any other fs. That suggests that my problem is something severe, like the boot kernel doesn’t know btrfs. Evidence is mounting for the boot env just not supporting btrfs.

12

If your root partition is a btrfs subvolume, then you’d need to pass that to the boot entry via rootflags=subvol=yourrootsubvolume, but grub-mkconfig will do that for you if you’ve mounted everything correctly in your live system chroot.
Other than that, the only boot-related requirement I can think of is having btrfs in the initrd.

13

@florian, @lcts, thanks for your suggestions. I was aware of all that, though. I’m not worried about a problem upgrading to F33; I assume ext4 and LVM will be support a very long time in the future as there’s nothing wrong with them.

I’m asking because I want to learn about this conversion, which I think is pretty novel and cool. Also, the value of btrfs is not limited to LVM features. The wiki makes a strong case for btrfs over ext4 for other reasons, such as space efficiency, COW, live defrag, and more convenient snapshots. Trying to do things like this makes me a better sysadmin. As you see, there is something about the boot process that I’m learning as I fight is problem.

1 Like
14

I didn’t create a subvolume for my root after conversion, so I assumed that the system doesn’t require that parameter. Also, mkconfig didn’t change any of the kernel params.

I think the core issue is btrfs not being in initrd.

However, you all convinced me to try to upgrade first to F33, then try the conversion later. If btrfs is default for F33, then it seems likely dracut will be sure it build initrd with it, and I will not have to trick it into adding that. If I still have the problem converting after that, we can think about it more.

Hmm, can I check initrd img to see if btrfs support is there? I know you can specify filesystems to dracut, but they are not kernel modules, so, where do they show up in the image filesystem?

15

Okay, I upgraded my VM to F33–which is not even in in beta, yet, BTW–and how I see btrfs in the initramfs image. So, that’s a really good sign; my guess was right and I don’t think I will need to tell dracut to add btrfs now. I don’t even think I will need to rebuild intrd at all.

16

Oh man, no joy. This time, it didn’t even transfer to the fb graphical boot spinner.

17

Okay, so I’m not crazy and something broken. I did the conversion exactly as described on the wiki. The results seem to make sense and I can mount the new volume exactly as it shows I should. But, it will not boot correctly. The initramfs has btrfs, so it’s not that.

The only thing left is boot parameters. But, mkconfig didn’t change them, so something is wrong.

18

Okay, so hopefully someone can help me interpret this situation. I can mount the converted fs fine using ‘mount ’ just like normal, i.e. by specifying the block device of the fs. The mount looks fine and says btrfs type, no subvolume option needed. But, only one subvolume is shown:

# btrfs subvolume list  /mnt
ID 256 gen 570 top level 5 path ext2_saved

Maybe this is right, but I was expecting the “default” subvolume to also show up in this list. Is that not right? I think it is called “/”. Does this mean something failed during conversion?

Also, ‘btrfs’ says the block device containing the filesystem, isn’t btrfs type.

# btrfs subvolume list /dev/mapper/fedora-root 
ERROR: not a btrfs filesystem: /dev/mapper/fedora-root
ERROR: can't access '/dev/mapper/fedora-root'
# btrfs subvolume list /dev/dm-3 
ERROR: not a btrfs filesystem: /dev/dm-3
ERROR: can't access '/dev/dm-3'

But, that’s the device I gave mount to mount the filesystem, which worked. But, fsadm and fsck both tell me that it is a btrfs filesystem.

# fsadm check /dev/mapper/fedora-root 
fsadm: Filesystem "btrfs" on device "/dev/mapper/fedora-root" is not supported by this tool.
# fsck /dev/mapper/fedora-root 
fsck from util-linux 2.35.1
If you wish to check the consistency of a BTRFS filesystem or
repair a damaged filesystem, see btrfs(8) subcommand 'check'.

And btrfs check doesn’t have a problem with it either.

# btrfs check /dev/mapper/fedora-root 
Opening filesystem to check...
Checking filesystem on /dev/mapper/fedora-root
UUID: d2af1a74-1f6e-412e-afad-d5cd2af22be0
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 11726327808 bytes used, no error found
total csum bytes: 11295060
total tree bytes: 462733312
total fs tree bytes: 439123968
total extent tree bytes: 9355264
btree space waste bytes: 80034471
file data blocks allocated: 276887678976
 referenced 21987827712

I don’t understand. What does it mean that btrfs check works, but btrfs subvolume list does not work on the same device?

19

That is fine. In fact, it is excellent. The fact that it is showing ID 256 and top level 5 means it is not the btrfs root subvolume, so you should be able to go on from there and create the btrfs recommended “flat” subvolume layout, where every new subvolume is also a child of the btrfs root subvolume.

https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Flat

20

Also, some btrfs commands only work on mounted volumes, that’s why btrfs subvolume list fails on /dev/mapper/fedora-root etc. but not on /mnt.