Announcement
Collapse
No announcement yet.
Move a BTRFS root file system install to a subvolume
Collapse
This topic is closed.
X
X
-
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:
Code:btrfs su cr /mnt/@home cp -a --reflink home/. /mnt/@home/.
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
- Top
- Bottom
Leave a comment:
-
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.
- Top
- Bottom
Leave a comment:
-
Move a BTRFS root file system install to a subvolume
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
Code:sudo mkdir /mnt/install
Code:sudo mount /dev/sda2 /mnt/install
Code:cd /mnt/install
Code:sudo btrfs su sn . @rootfs
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
Code:sudo umount /dev/sda2
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!
Tags: None
- Top
- Bottom
Users Viewing This Topic
Collapse
There are 0 users viewing this topic.
Leave a comment: