I usually prefer to do a fresh install, and keep just /home untouched. Back on pre-33 LVM days, it was intuitive, I just needed to remap existing partitions (/home was on a separate partition) to the new installation, and mark / , /boot and /boot/efi to be formatted. Now that I am using Btrfs, I can remap /home, /boot and /boot/efi, but I can’t do the same with / , I have to “create it” first. Since /home is a Btrfs subvolume, will the creation of the “new” (formatted) / affect /home ?
Also, if I try to remap both /boot (xfs) and /boot/efi (vfat?) to the new installation, installer warns me that both partitions will be destroyed, but only /boot (xfs) will be created. That is really confusing…
So, basically, what I would like to know is: how can I use Anaconda installer to install a fresh F34 on top of an existing F33 Btrfs installation, leaving /home untouched and reformatting everything else?
Here is the current partitions info:
/dev/sda3 232G 45G 187G 20% /home
/dev/sda2 1014M 280M 735M 28% /boot
/dev/sda1 200M 8,6M 192M 5% /boot/efi
btrfs subvolume list /
ID 256 gen 536357 top level 5 path root
ID 257 gen 536357 top level 5 path home
ID 263 gen 536295 top level 256 path var/lib/portables
ID 268 gen 536295 top level 256 path var/lib/machines
Thanks, that’s good news regarding ‘/home’ But now AFAICS I will end up with two volumes for ‘/’: ‘root’ (current) and ‘root00’ (the one Anaconda will create). How should I get rid of the old ‘root’ after F34 is installed without compromising the existing installation? Should I just remove the old ‘root’ volume?
I know this is probably “Btrfs 101”, I did some googling about this to try to figure it out myself, but I was still unsure about how to deal with this selective installation of F34. Maybe Anaconda could handle this scenario in a simpler way eg. by allowing the user to “remap” old ‘/’ as it does with LVM, even though on the background it would actually create a new ‘/’ and then remove old ‘/’ automatically after the installation.
PS: Thank you @ankursinha for reposting this as a new question
When Fedora 34 is up and running, after you are sure that certain subvols are no longer needed, you can simply remove those subvols without affecting other subvols (snapshots included).
It’s not obvious to use the [+] button to create a new mount point for / but that is the loophole allowing a new subvolume to be created (by the installer) for the clean install, while also using an existing subvolume mapped to the /home mount point. You can delete the old root subvolume in the installer if you wish.
How should I get rid of the old ‘root’ after F34 is installed without compromising the existing installation? Should I just remove the old ‘root’ volume?
After installation you can delete it by:
# cat /etc/fstab
# mount /dev/sdXY /mnt
# cd /mnt
# ls -l
# btrfs subvolume delete $SUB
The idea is to look at the fstab for the currently booted system (the current subvolume being used), see what subvol= is set to, and make sure you do NOT delete that subvolume. Delete the other one(s). The delete subvolume command is fairly immediate and final, so you want to be certain!
I know this is probably “Btrfs 101”,
It’s not. It’s a bit non-obvious and it’s all new, so it’s best to ask the question rather than stumble in the darkness. Also UI/UX is hard, so it’s understandable if you see a line in a “Reformat” checkbox to be concerned whether your home data is subject to that reformat or not.
Maybe Anaconda could handle this scenario in a simpler way eg. by allowing the user to “remap” old ‘/’ as it does with LVM, even though on the background it would actually create a new ‘/’ and then remove old ‘/’ automatically after the installation.
It’s a bit misleading to treat subvolumes as block devices. In the case of LVM LV used as / we’d choosing an existing block device and formatting it, which isn’t how Btrfs subvolumes work. We definitely need a way to describe how to do this.
For the record: it worked as advertised Thank you guys!
Yes, I can definitely testify it is not obvious BTW great tip about being able to delete the old root subvolume right in the installer I wish I knew it before…
I did some googling around, and there is a lot of confusion regarding the removal of subvolumes. I wasn’t being successful either, operation was failing with some meaningless error messages (“invalid argument”). Your tip was on point though: mounting the whole device allowed me to finally remove the intended subvolume.
Thanks for acknowledging that the UI/UX is a little misleading on this case. Yes, I agree, IMHO btrfs definitely deserves to be handled differently to avoid confusion.