For future reference: I cannot recommend moving partitions with any partition utility under any circumstances. I personally consider this to be a misfeature because this process doesn’t have any sort of journaling, checkpointing, or rollback.
There’s long periods of time when moving partitions that file systems are functionally broken, and if a power failure or crash occurs during this period - it’s unrecoverable.
So I just can’t recommend it. It’s not safe. And also it’s not faster than the alternative, which is already having a backup of your important data, and just obliterating the entire disk and reinstalling everything with the partition layout you want.
Re: using btrfs device add
to add partitions. This works fine, I ran Fedora for a year in this configuration for the same reasons. There’s no downside in a non-encrypted regime. Of course in an encrypted regime you’d want to use the same passphrase for the two partitions, that way plymouth can unlock both at the same time (using the same passphrase). The DEK is different, and that’s fine.
While you can do a clean install of Fedora preserving home
subvolume to an existing btrfs, this assumes you’re not repartitioning and reformatting. But in your case, repartitioning is the point of the clean install, and in that case you’d need a backup of home
so it can be restored.
This is pretty straightforward on btrfs, pseudo-code is like this:
# mount $DEV1 /mnt/1
# cd /mnt/1
# btrfs sub snap -r home home.20250204
# mount $DEV2 /mnt/2
# cd /
# btrfs send /mnt/1/home.20250204 | btrfs receive /mnt/2
$DEV2 is a separate drive, formatted btrfs. The gist is you’re making a read only snapshot and replicating it from main drive to backup drive. This replication preserved everything, all files, metadata including DAC and MAC security, etc.
All that gets torn down and you do the clean install, and then either in the LiveOS environment after installation, or reboot from installation you do:
# mount $DEV1 /mnt/1
# mount $DEV2 /mnt/2
# btrfs send /mnt/2/home.20250204 | btrfs receive /mnt/1/
# mv /mnt/1/home /mnt/1/home.delete
# btrfs sub snap /mnt/1/home.20250204 /mnt/1/home
Here you’re sending the read-only snapshot back to the new clean installed system, renaming the current home subvolume, and you’ll delete that later; then making a read-write snapshot of the read-only snapshot of your replicated home. And now you reboot.
It does not mind that you’re renaming things behind the scenes, no rugs are being pulled out from anyone. When you reboot your old home is restored. Optionally delete the home.deleted subvolume.
Now this does assume you add users in the same order and using the same shortname they had originally. Added users get their UID in order of creation, and that’s in /etc/shadow, which needs to match the UID for the user’s directory found in /home
. If this isn’t the case then you’ll have additional changes to make e.g. chown -R