Btrfs subvolume support in the installer

hello, would it be possible to add an option to the installer for people like me that do not need or want to farmat disks. I use subvolumes and i have a main OS handling grub aswell… The installer has no option to let me install on /mnt that i previously mounted myself. Like this we would be able to install on subvolumes .

1 Like

I pushed a commit that should do this but I’m not gonna package it before some testing

curl -fSL https://bitbucket.org/archlabslinux/installer/raw/master/archlabs-installer -o /usr/bin/archlabs-installer

archlabs-installer -n -b BOOT_DEV -r ROOT_DEV
1 Like

We only make you format the root partition, I don’t know much about btrfs but I do know you can expect issues if you install overtop of an existing OS root without formatting, but the option is there now.

hmm could you add just a mountpoint option? like where we can specify /mnt as mountpoint and it will install there… i am asking that because i use btrfs subvolumes and they are not actual devices shown as /dev/xxx

1 Like

You can already specify the mountpoint with an environment variable, this has been the case for a long time

MNT="/path/to/root" archlabs-installer

That doesn’t remove the need to know what devices are what though.

I can do like you’re saying sure; but you’ll have to figure out the fstab, bootloader config, and anything else that relies on knowing what device/partition/subvolume is used where.

If btrfs subvolumes are not a block device file in /dev/ then where are they? I’m fairly sure they’ll be in there as that’s the “device” pseudo-filesystem, where else could they be really!?.

Subvolumes are file extant-based and so do not expose themselves as devices.

If the installer didn’t try to format the device in the partitioning section then that would allow the user to pre-mount the subvolume like this:

mount -o subvol=archlabs /dev/sda1 /mnt

Then run the installer and tell it that /mnt contains subvolumes and so shouldn’t be formatted or assigned to a partition automatically:

SUBVOL='yes' archlabs-installer

This was done in my first reply to this thread

I was under the impression this had been tried and did not work.

I just know that some things will fail due to the installer needing something to query for (mostly) UUID.

Surely once mounted this must have a file path? Similar to LVM?

Additional unrelated question, does btrfs require a supporting bootloader?

No, the subvolume just appears under /mnt. The subvolume identity is visible in /proc/self/mounts though:

/dev/vda1 /mnt btrfs rw,relatime,space_cache,subvolid=256,subvol=/archlabs 0 0

^ That also shows how the fstab line should be written (gen-fstab accommodates btrfs subvolumes).

All that is needed is a kernel command line option to identify the root subvolume, for example:

rootflags=subvol=archlabs

Ok I think I understand.

Would this not work as the root device passed in, that way we have something to lsblk and part-uuid against.

I can tweak around with the settings/script as issues are encountered, right now we just need someone to take the plunge and try an install with the current version of the installer.

I’ll try it now…

1 Like

If you have a btfs setup, post me your lsblk -fa output, just curious.

If this goes on for a while I’ll get my shit together and setup btfs on a system to try.

Truncated (sorry but it’s from a VM without copy&paste):

└─vda1 btrfs $uuid 9.5G 0% /mnt

$uuid is the UUID of /dev/vda1 but blkid also lists a UUID_SUB for the subvolume.

That’s all I needed to see anyway.

Ok so it’s definitely something we can find and work with. We do use blkid for everything but LVM as it’s just /dev/mapper/name. Perhaps btrfs should be along the same lines where we don’t worry about the uuid, though it might be needed for subvolumes? (not knowledgeable enough to say myself).

You’re in the midst of seeing if/where the installer fails? No pressure on your end but I can push updates fast if you run into anything.

Starting to seem more and more like proper support in the installer for it like LVM would be the best solution, still on the fence though as it’s not something a lot of users are using and not familiar with it myself (but a day or two deep dive isn’t out of question).

MNT="/path/to/root" archlabs-installer

this is exactly what i was looking for, as i manage grub from a different system i only need to install, without grub. thank you i will test it out

The UUID will be needed for /etc/fstab but genfstab creates a working line.

It won’t let me proceed without formatting the root partition.

Steps so far:

mkfs.btrfs /dev/vda1
mount /dev/vda1 /mnt
btrfs subvolume create /mnt/archlabs
umount /mnt
mount -o subvol=archlabs /dev/vda1 /mnt
BOOT_PART='/dev/vda1' ROOT_PART='/dev/vda1' archlabs-installer

Regarding this, the reason I haven’t specified this is that the default location is /mnt (most people expect this so it makes sense) so you shouldn’t even need to specify.

I still suspect you’ll run into issues during install, they won’t be severe.

Use the new flags in my first reply to this thread need to update the installer with the curl command - v2.1.48

Both accomplish the same for root/boot partitions, just the -n flag signifies to not bother with partitioning, mounting, or formatting. You’ll know immediately as a background install process will be one of the early dialogs after network.

Ah yes, sorry, I’m distracted by three other forums here :grin:

Just used that and it seems to work, installing now…