disclamer: quite long post, sorry for verbosity
In my transition to EOS from another arch-based distribution, I am willing to attempt a switch to gpt+btrfs system as well.
Before approaching the actual installation process, I have examined several sources - starting from the very informative threads in this same forum (list for future reference):
- @2000 step-by-step detailed wiki article and related thread
- @TomZ approach to btrfs
- @pebcak installation experiments and @dalto answers suggesting what I am attempting to do is feasible, somehow
- Archwiki btrfs and snapper entries
- Btrfs wiki, in particular the Sysadmin section about subvolumes
- Gentoo wiki
- Garuda Linux Gitlab repo, knowing they use btrfs as default, looking at how they deal with it in Calamares
My layout plan (w/encrypted luks):
- base as per @2000 article, 8M gpt and btrfs for the remaining space, with subvolumes @ and @home automatically created by calamares
- create additional subvolumes for /var/cache, /var/log, /var/tmp, ~/.cache (plus @/swap for hibernation and /.snapshots for subsequent Snapper use).
- /var subvolumes nested within /@ parent and .cache within /@home, as it initally sounded a logical thing to do
In spite of homeworks, I was unable to achieve this, probably because I really haven’t fully grasped the nature of subvolumes.
Following a mix of @2000 guide and Archwiki (possible first mistake: mixing), I tried to create /var subvolumes - eg.
sudo btrfs subvolume create /mnt/btrfs/@/var/log - being greeted by ERROR:target path already exist (first sign I haven’t understood properly subvolumes).
Then I thought that since paths already exist, I might “just” have to deal with mounting them, so I tried to mount /dev/mapper/… /var/log into subvol @/var/log, encountering though wrong fs type, bad option, bad superblock, missing codepage or helper program or other error.
As things made less and less sense from the ideal picture I had in my mind, I came to terms with my inability to understand and compromised for a full-flat layout, attempting to create subvolumes at the same level as @ and @home, but ultimately resulting in a convoluted mess of parents and children - eg. subvolume create /mnt/btrfs/@var and subsequently /@var/log (in one of such experiments I managed to create @var/cache/pacman/pkg, each sub-branch being its own subvolume and children of the preceding one, just to give you an idea of the desperation level reached).
Final attempt with
btrfs subvolumes create /mnt/btrfs/@var-cache and mounting it with
mount -o subvol=@var-cache dev/mapper/... /mnt/btrfs/@/var/cache resulted in both empty @var-cache subvolume and actual directory @/var/cache.
Several stops at Google and StackOverflow didn’t help in clearing skies from the foggy mess.
I know I’d likely have to deal with moving data (rsyncing?) and creating fstab entries as highlighted by @dalto here, but ultimately I am missing several pieces.
It’s evident at this point I got the whole btrfs subvolumes idea wrong, but still I really wouldn’t like to surrender and go back to ext4 LVM-LUKS layout. May then any kind soul with a working knowledge of btrfs come to rescue and put some salt (and solid judgment) in my relation with subvolumes?
Dulcis in fundo, just to further spice up things, gpt partitioning didn’t really work as well, resulting in unbootable system.
Have to say I am attempting all this on my quite ancient (but still doing its job), pre-uefi laptop (around 2010 if I’m not mistaken, upgraded with ssd), hence bios probably isn’t able to see ee gpt partition as bootable. The trick of
fdisk -t mbr /dev/sda didn’t really work, but before trying the
sudo printf ‘\200\0\0\0\0\0\0\0\0\0\0\0\001\0\0\0’ | dd of=/dev/sda bs=1 seek=462 as suggested in archwiki (and prematurely sending the ssd to heaven in case it screws up) I would kindly welcome a second opinion from you guys.
Thanks for your patience and sorry for my dumbness.