Clone a Fedora install without `dd` & from bigger to smaller drive

I need to clone my current Fedora install from a bigger “2TB” (1,8TB) SSD to a smaller “1TB” SSD.

Using dd should not work, as the BTRFS partition on the target drive needs to be smaller than on the origin drive.

I have found an interesting comment on this with details about something, but this is not relevant here I think (MBR, rsync, no BTRFS).

Using rsync for anything outside the user home is not an option as it does not copy any SELinux labels! And with confined-users this should probably also avoided within the home dir.

(btw. What should we use instead?).

Because of a TPM related Anaconda bug I can also not boot the current F40 install media (tried Kinoite and secureblue kinoite-main-userns-hardened).

The drive had the /boot and /boot/efi partitions already set up, but not sure what distro.

I tried creating a LVM using KDE Partitionmanager for the data partition, as I want to switch away from BTRFS to F2FS.

I will look into the LVM creation, but when the partitions are done, I still wonder how to migrate from BTRFS subvolumes to LVM volumes, how to sync the data while keeping all the attributes etc.

I would be fine with just an option to clone my current BTRFS setup to a smaller disk, automatically making the last BTRFS partition smaller.

OR manually cloning each partition, creating the BTRFS partition and using something, maybe btrbk for the cloning.

I just started with the easier approach:

  • standard GPT partition table
  • create 1GB /boot in EXT4
  • create 600MB /boot/efi
  • create 8GB swap
  • create the rest with BTRFS encrypted

Then I used dd to clone /boot and /boot/efi from my NVME to the SSD.

Now I am looking for a way to clone the BTRFS part.

I am still interested in the BTRFS → LVM transition though, but one thing at a time.

1 Like

--xattrs, -X preserve extended attributes:
This option tells rsync to preserve the SELinux security context of the source files when copying them to the destination.

Here is a snippet of what i used to do. . .

rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/home/"} for a specific purpose. Can remove Home if needed.

  • -a (Archive mode):
    • Combines several options to ensure that a comprehensive set of file attributes are preserved. Specifically, it includes -r (recursive), -l (copy symlinks as symlinks), -p (preserve permissions), -t (preserve modification times), -g (preserve group), -o (preserve owner), and -D (preserve device and special files).
  • -A (Preserve ACLs):
    • Ensures that Access Control Lists (ACLs) are preserved during the file transfer. ACLs provide a more fine-grained permission mechanism than the traditional Unix file permission system.
  • -X (Preserve extended attributes):
    • This includes SELinux contexts, as well as other extended attributes that files might have. It ensures that all the metadata associated with a file is copied over.
  • -v (Verbose):
    • Increases the verbosity of the output, providing detailed information about what rsync is doing during the file transfer.


I’m not going to comment on the other tools that claim to be faster than rsync. I used this way back in F25 (4.19.x) because of how bad that build was for me for many reasons. I use rsync for a far smaller use case nowadays, but this worked so well. I do recall having to pay attention to UUID’s and my /etc/fstab, /etc/crypttab :thinking: I think I went from ext4 & XFS a couple times, and had an NTFS drive too.

Edit :

Blivet is how I made my partitons when I did fresh installs of Fedora. LVM + LUKS + XFS.

Here is an old thread of mine :

Future Edit :

  • Create your LVM ( Physical Volume, Volume Group, Logical Volume)
  • Format the LVM - mkfs.xfs /dev/my_vg/my_lv) I use XFS. . .
  • Create the LVM Mount Point - mkdir /mnt/my_new_volume
  • Mount the LVM - mount /dev/my_vg/my_lv /mnt/my_new_volume
  • Rsync the data - rsync -aAXv --progress /path/to/btrfs/subvolume/ /mnt/my_new_volume/
    This worked for me, again there are some quirks because of UUID
  • blkid /dev/my_vg/my_lv & vim /etc/fstab & /etc/crypttab

If you move to LVM you should add Snapshots.

You can create a script to automate Snapshots before an update and even have a dnf hook with a small file.


I have used btrfs-filesystem resize then gparted to adjust shrink the btrfs partition on a dual boot system in order to add space to the Windows partition. I would not attempt this without a verified good backup or two.

See: btrfs resize and man 8 btrfs-filesystem resize. If you succeed in resizing the btrfs filesystem, you can then resize the partition using gparted.

1 Like

Yes that was kinda mentioned somewhere. But I dont want to change my system, as I will still use it.

But for sure this would be a clean solution.

Personally, I would do a read only snapshot of my current using btrfs, then use btrfs send/receive to send it to my new drive (change it back to a RW volume. Mount the new volume and modify the fstab to have the new uuid.
Of course, providing this is all on a btrfs partition.
Edit: you also have to put the UUID of the newly created subvolume into the kernel command line for booting.


“partclone.btrfs -b -s /dev/sda3 -o /dev/sdb3” could possibly do it

assuming the source partition data would fit in the destination partition.

The partitions should not be mounted, meaning you’ll have to start the process from an usb key or live dvd.

When you want to mount either the source or destination partition after cloning, the 2nd drive shall be unplugged from the computer. Because they have the same UUID, which leads to catastrophic results with btrfs.

1 Like

That… sounds complicated.

Why do a snapshot if I just send it?

Why edit the fstab if I dont change the partitions?

I will try the solution of @josevillani and gave up on LVM haha

To send/receive with the btrfs tool the snapshot must be read only. Snapshotting a btrfs subvolume as ro is not really that comlicated, it’s a oneline command in your terminal.

Because the UUID of the new subvolume created from sending the snapshot in the first place will be different. Otherwise what’s the sense in having unique identifiers?

This isn’t LVM, just the tools available with Butter FS. You could use the Btrfs Assistant to do the snapshot.
I have done this with my home when I moved it to a larger SSD from what it was on, which was spinning rust.

Snapshots take very little space, almost none. The send/receive took the most time, like rsync type of time.

1 Like

ok well I have 2 solutions here, and will see if I can choose the LVM instead.

To my knowledge, I dont ever need BTRFS snapshots, but the general performance is supposedly better than the one of BTRFS.

Also people complained about the complexity of BTRFS not being KISS.

Then I see F2FS is pretty stable and flash-optimized, while EXT4 and XFS are both also meant for “spinning rust”.

So I think I would go the LVM way (when I have the time) and comment the exact way I did.

1 Like

I dunno, I didn’t find doing a snapshot too complex, nor the send/receive, where I originally (ie the first time I tried it) got hung up was not making my original snapshot ro. Doing it with Btrfs Assistant is even easier as you don’t even need to know the command line commands. The other benefit I found with Btrfs Assistant is it will work with systemd-boot to create roolback booting capabilities. Although I haven’t tried setting it up, or tested it on my system.

This image show the assistant with my home backup, but in order to use the rollback I would have to be backing up / and /var which I am not at this time. As you can see, snapper boot can be enabled and the changes can be applied to systemd. If someone else is using this, it would be goods to know what the success is/was.
Note: Btrfs Assistant will not do the send/receive AFAIK though, so that still needs to be done at the command line.

1 Like

I will try btrfs-assistant or just find out the needed commands.

I dont really see the point in local snapshots of files, as they will be pretty huge and external backups are better.

But they are still likely useful for having a backup if you delete the wrong file… but restoring just a single one? I dont know.

Snapshots take next to no space as they do not copy data on the same device, just reflinks. The same as when you copy a file on btrfs, it’s normally a reflink unless you specifically tell it to copy data too. Send/receive does make a data copy, and it can be encrypted for send. If you want I can document the command line steps I used for moving my home subvolume to another drive.

1 Like

So If I move a ton of files and make a backup, that would be small.

If some cache etc is included though, it might be bigger.

Can directories be excluded, where typical temp stuff is stored?

(Sorry I just need to rtfm lol)