Move a BTRFS root file system install to a subvolume

[oshunluvr]

Long story how I ended up here (the "Why" later in the post), but I recently used an installer that put the BTRFS install onto the root btrfs file system rather than into a subvolume as is the *buntu custom. This is less than optimal as much of the benefit of using BTRFS comes from the existence of subvolumes. The following is totally new functionality to me - either it's new or I just didn't know it.

On to how I did it:

Booted to the install
Created a target to mount the root fs

sudo mkdir /mnt/install

Mounted the root fs

sudo mount /dev/sda2 /mnt/install

CD'd into the mount

cd /mnt/install

Made a snapshot of the root fs

sudo btrfs su sn . @rootfs

And voilà I have a snapshot of my root fs!

The nesting is very odd. From the root fs the path to the snapshot is
/mnt/install/mnt/install/@rootfs
Once I unmounted the root fs

sudo umount /dev/sda2

the snapshot is visible in /mnt/install/, and checking the mnt/install folder inside the snapshot - it's empty.

Part of the "Why" is this btrfs installation is in a VM. For whatever reason, the installer (this is Ubuntu Server 22.04 beta) does not use subvolumes at install like all other *buntu installers are. I don't know if it's a change or a different installer - it certainly felt different! So I installed it into a VM so I could do the above and then move the subvolume to my server for testing.

To do this, I did a "btrfs send" and sent the subvolume from the VM to a file on a shared folder on my host system. Then once it was there, did "btrfs receive" and again voilà I have a subvolume. Next - on to whether or not I can actually boot this subvolume on my server!

[jlittle]

Cool. I'm hanging out for the result.

In principle, Linux doesn't care much about where its root is, so long as it can find itself from the linux command line (used by the boot loader), and /etc/fstab corresponds.

It might be possible to do the install straight to the target btrfs, boot to another OS instance (such as a live USB), create a subvolume, then cp -ar --reflink everything into that subvolume. If there are other installs or data in that btrfs, I'd worry that the install might trample on them, but maybe it wouldn't. I might give it a try one day I have some storage I don't mind reformatting.

[oshunluvr]

The info I read suggested using cp with reflink to create a home subvolume rather than the above procedure. I think, depending on the size of your home folder,it might be faster to make the full fs subvolume, then delete everything not in /home. Obviously, if you were doing this right after initial install like I did, then the cp reflink would be very quick.It would be an interesting experiment.

Assuming you mounted the root fs at /mnt, it would be as simple as:

btrfs su cr /mnt/@home
cp -a --reflink home/. /mnt/@home/.

Since this was a new install and only for server use (the ISO was jammy-live-server-amd64) I do not keep a separate home subvolume.

As far as the overall project (the real "Why"), I was able to:

• Move the install on the VM to a subvolume as described above
• Use "btrfs send -f" to send a read-only snapshot from the VM to a shared folder on the host
• Copy the btrfs file from the host to my server computer over NFS
• ssh into the server and "btrfs receive -f" the file back into a subvolume and set the r/o snapshot as r/w
• Edit the grub.cfg and fstab to reflect the change in UUIDs
• Boot it

I booted it using my current server installation using a custom grub stanza. Now that I know it works, I can boot into the 22.04 server VM when I have time to work on transition items and test it in the VM. Once it's all done and ready, I will redo the export of the subvolume for a smooth change over to the new version.

[GreyGeek]

Very clever, oshunluvr!!! 👑