7

With filesystems like ext4 if I want to try a new Linux distribution I have to first shrink existing partitions then create a new partition that's locked to a certain size where I can install the distro. This has a few drawbacks:

  • Have to commit a certain quantity of storage to the distro exclusively right off the bat
  • Difficult to reallocate this storage if it goes unused
  • Disk operations are somewhat tricky, especially moving things around to create contiguous free space

Do BTRFS subvolumes solve this? Can I really just make the entire disk a volume/partition and then my boot, swap, root, and home partitions can just live as subvolumes and take up however much space they take up? And I can create a new subvolume initialized to zero size whenever I want? Is this really how it works?

Improve this question

3 Answers 3

Reset to default
10

I have get it works, partially.

From an OpenSUSE installation (btrfs used by default), I have:

  • created a subvolume (btrfs subvol create /debian),
  • installed debootstrap,
  • deboostrap --arch=amd64 stable /debian http://deb.debian.org/debian/,
  • in a chroot /debian, install btrfs-tools, then a kernel, and set a password !
  • back in the OpenSUSE root shell modify /boot/grub2/grub.cfg, add one entry.

Typically, I have dupplicated an OpenSUSE entry, change the name (Debian), and add on the linux line, rootflags=subvol=@/debian. I also use the Debian kernel and initrd files (linux= and initrd= lines). Note, GRUB search the default root FS, then both files are in /debian/boot/)

Reboot... And I have a Debian boot entry which start Debian from the debian subvolume. It doesn't mount anything by default, but mount -o subvol=@/home /dev/sda2 /home for example can mount the OpenSUSE /home subvolume and make it available on Debian too. Of course, editing the /etc/fstab would make things permanent. (And using UUID is better).

This installation is not completely satisfactory. Updating the kernel on Suse will erase the GRUB Debian entry. And updating the kernel on Debian will not update the GRUB configuration. (the GRUB os-prober only scans the partitions, not the subvolumes).

But, my setting proves we can have multiple Linux installations on the same partition with btrfs.

Note OpenSUSE names the root subvolume @. We can see it with btrfs list /. I don't know if other distributions use other conventions. The very first line of btrfs subvol show /debian gives you the name to use with rootlags=subvol=

Improve this answer
1
  • The file to add custom GRUB entries is /etc/grub.d/40_custom, not the machine generated grub.cfg
    – André Werlang
    May 11 at 19:10
7

Yes, you can. Looking at each of the big-name distributions:

  • Gentoo can be trivially installed this way by using the standard Gentoo install procedure from an existing install of pretty much any other recent distribution.
  • Alpine Linux can be trivially installed this way by using one of their mini root filesystems (instead of their ‘normal’ install method), again from an existing install of pretty much any distribution.
  • Arch Linux can mostly be easily installed this way using it’s normal install procedure, but requires special handling around the bootloader configuration.
  • Debian can relatively easily be installed this way by using debbootstrap (which is designed for installing from a live system) from an existing install and then manually configuring the bootloader.
  • Ubuntu can theoretically be installed this way using debbootstrap just like Debian, but AIUI such an install is fully unsupported by the Ubuntu developers, so it probably does not work reliably.
  • openSUSE, Fedora, and most RHEL clones (CentOS, Alma, Rocky, Oracle Linux, etc) can theoretically be installed this way, but requires special manual configuration when setting up partitions.

However, there are a couple of practical issues with this approach:

  • While you can install most distros this way, they generally do not have great support for managing such a setup. In particular, you’re likely to have issues with bootloader configuration, especially if you pick distros that default to using different boot loaders.
  • Related to the above point, this type of setup is not used by most people, so it’s not well documented, not well tested, and you will likely have difficulty finding support if you run into issues with it.
  • BTRFS subvolumes are dependent on the filesystem itself. If one distro trashes the filesystem, you lose all the distros, not just the one that trashed the filesystem.
  • BTRFS subvolumes are not block devices. This differs from ZFS zvols or LVM logical volumes. You can, in theory, use one for swap space by just creating a swap file on it, but you probably just want a shared swap partition anyway (if you’re going with a multiboot setup, you should almost never be hibernating the system, which would be the only reason to need a separate swap partition for each distro).

In general, you will be much better off just using LVM in place of flat partitioning and creating a logical volume for each distribution’s root filesystem (plus one for /home and one for swap space). You will still have to set some baseline amount of space for each distro, but you can easily adjust things on the fly with LVM, provided you have filesystems that can be resized online (and that can be shrunk). Note that in this setup, you still need a ‘regular’ boot partition (and EFI System Partition). Unlike your proposed BTRFS setup, this is well supported by pretty much all major distributions, and provided you’re careful with the initial setup it mostly just works without any manual effort beyond the initial installs.

Improve this answer
2

I did have such a setup using ZFS - the concept should be similar with btrfs.

I used 3 partitions:

  • An ESP with refind on it
  • A swap partition (common for all the distros)
  • A ZFS pool where each distribuition's / was a separate volume (subvolume in btrfs-speak), and /home was common

On the ESP under the EFI dir there was a subdirectory for each distro (named to match the refind icon name for the distro). These directories were bind-mounted as /boot in the /etc/fstab of the respective distribution (IIRC something didn't like boot being a symlink, so I went with a bind mount), and they contained the kernel, initramfs, and a refind_linux.conf with the boot parameters.

Refind autodetects each dir as a boot entry and will boot the newest (by timestamp) kernel by default - no need to deal with the complex grub configuration, the grub package can be removed from each install.

The only potential problem was that initramfs-tools could not generate the initramfs on a FAT32 partition (it wanted to create symlinks), so I used dracut everywhere as it's superior anyway.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .