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.
system-config-lvm is supposedly deprecated and used python2 and GTK2
blivet-gui is likely the Fedora recommended option, but it needs GTK on the system.
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.
--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.
Thoughts
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 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.
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.
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.
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.
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.
I think I went from ext4 & XFS a couple times, and had an NTFS drive too.