Btrfs and clonezilla

[mr_raider]

Is there something about btrfs that makes clonezilla spaz out?

I'm trying to clone an install from 256gb external USB drive to an internal 1gb nvme drive and it seems to fail.

The EFI and non btrfs partitions copy over fine, but the btrfs doesn't. Grub fails at loading initramfs and the cloned btrfs partition is unmountable.

Any ideas?

[GreyGeek]

A BTRFS rootfs cannot be cloned using Clonzilla or other similar application because the process does not transfer the UUID or extents.
The BTRFS tools supplied has a cloning tool called btrfs-replace You can read its man page to learn about it. Its command is
btrfs replace start [-Bfr] <srcdev>|<devid> <targetdev> <path>
NOTE:

Never use btrfs replace start for backup-purposes!! It corrupts your device tree and makes the drive unmountable! It was impossible for me to recover from the errors, so I restored an image copy from another block device with the dd-tool. Only use btrfs replace for final drive migration.
– Karmus

Use btrfstune -u to change UUID after copy and before mounting.

OR

you can find a btrfs-cloning tool at https://github.com/mwilck/btrfs-clone

It's command looks like
btrfs-clone [options] <mount-point-of-existing-FS> <mount-point-of-new-FS>

Here is an example that is given:
[QUOTE]
mkfs.btrfs /dev/sdb1
mkdir /mnt/new
mount /dev/sdb1 /mnt/new
btrfs-clone.py / /mnt/new
[/QUOTE]
The system to be cloned booted and running on "/" and it is cloned to sdb1 mounted on /mnt/new
If you have @home mounted on /home then you'll have to clone it to /mnt/new as well.

After the cloning is done you can check the clones by using rsync:
rsync -n -avxAHXS <src-subvol> <dst-subvol>
i.e.,
rsync -n -avxAHXS / /mnt/new

[jlittle]

Is there something about btrfs that makes clonezilla ... fail ... the cloned btrfs partition is unmountable.

How did you try to mount it? Was the source fs mounted, or even in the system? (If the source partition is not present, there shouldn't be UUID problems.) It would be interesting (to me) what gparted says about the partition.

I recently tried to move a btrfs partition, using KDE Partition Manager from a live USB, and it appeared to move successfully, but afterwards

• KDE Partition Manager did not show the partition at all
• gparted could see it but said "unknown file system"
• grub could not see into it, using ls at the grub prompt
• nothing could mount it

I didn't have time to investigate, so I recreated a btrfs and restored the system from a backup (one of several made before attempting the move). In my case there shouldn't have been UUID problems.

After restoring the backup grub needed help, as the UUID had changed, but I had a grub entry that doesn't have UUIDs sitting in custom.cfg and that booted fine. Without that grub entry I would have had to chroot into the OS to run grub-install from it. That is the standard solution to your grub failure, but I suspect that the grub failure you report was due to grub not being able to read the fs to find the initramfs.

If I have the time, I'd like to do it again, and to use clonezilla to make a copy, so that I can checksum the original partition and the new versions.

The btrfs-clone tool GreyGeek suggests is interesting to me because it handles multiple subvolumes. After restoring my backup, I had to manually recreate various subvolumes I don't normally back up, like @downloads, @appimages, and @cache.

[mr_raider]

How did you try to mount it? Was the source fs mounted, or even in the system? (If the source partition is not present, there shouldn't be UUID problems.) It would be interesting (to me) what gparted says about the partition.

I recently tried to move a btrfs partition, using KDE Partition Manager from a live USB, and it appeared to move successfully, but afterwards

• KDE Partition Manager did not show the partition at all
• gparted could see it but said "unknown file system"
• grub could not see into it, using ls at the grub prompt
• nothing could mount it

I didn't have time to investigate, so I recreated a btrfs and restored the system from a backup (one of several made before attempting the move). In my case there shouldn't have been UUID problems.

After restoring the backup grub needed help, as the UUID had changed, but I had a grub entry that doesn't have UUIDs sitting in custom.cfg and that booted fine. Without that grub entry I would have had to chroot into the OS to run grub-install from it. That is the standard solution to your grub failure, but I suspect that the grub failure you report was due to grub not being able to read the fs to find the initramfs.

If I have the time, I'd like to do it again, and to use clonezilla to make a copy, so that I can checksum the original partition and the new versions.

The btrfs-clone tool GreyGeek suggests is interesting to me because it handles multiple subvolumes. After restoring my backup, I had to manually recreate various subvolumes I don't normally back up, like @downloads, @appimages, and @cache.

I placed the old drive into an external enclosure, ran clonezilla to copy to the internal nvme. After clone I disconnected the external old drive and tries to boot the the new drive. Grub came up fine, but I got an initramfs error.

I booted from a live USB and tried to inspect the new btrfs partition but parted could not identify it and threw an error. It was not mountable, and btrfs check could not read it. As the post above suggests, clonezilla must have screwed the file system structure.

I will try to use clonezilla in sector copy mode (dd essentially) but that's a half day exercise. Will wait for the week end.

[mr_raider]

MAnjaro suggests the following method. Opinions?

Tips

Move a volume


There is an easy and secure way to move a volume to another disk/device. If you use Btrfs itself to move the volume, there will be no danger. You even can do this while the volume is in use.

• Create the partition you want to use as destination without formatting it. Or remove the filesystem when one is present
• Add the destination device to your volume by

root # btrfs device add /dev/[destination]

• Remove the source device from your volume by

root # btrfs device remove /dev/[source]

Btrfs will notice, that it is necessary for this setup to move all data from the source device to the destination device. And it will start immediately to move data in the background. Meanwhile you can use your PC as you want.

• Empty Blocks will not be moved
• Compressed data will remain compressed
• All Snapshots will remain
• The UUID of the filesystem will remain the same, but btrfs will be aware of this
• If you used the UUID to identify your volume, you even wont´t need to edit /boot/grub/grub.cfg and /etc/fstab
• Only, don't shutdown while the move of the volume is not complete.