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
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.