Ubuntu – Can 12.04 be installed using Btrfs only

I got rid of that entry by adding a fstab entry with a /mnt mountpoint, that would be:

/dev/sdc1       /mnt/nonexistent               btrfs   noauto        0       0
/dev/sdb1       /mnt/nonexistent               btrfs   noauto        0       0

for you.

(With some help from Stackoverflow )

Yes, you can. This is what I use at the very moment. The other cool thing is that you can bedup the partition after you have installed many similar OSes (like Ubuntu and Linux Mint) to conserve a lot of hard disk space.

The trick is to rename the default subvolumes: @ and @home into something unique to the distribution installation, e.g. @ -> @mint or @trusty and @home into @homemint or @hometrusty.

This can be done at any moment after the installation of the first system, before the installation of the second. The most error-safe way is to take a snapshot of the subvolumes, for instance like this:

1. mount root subvolume of the system btrfs partition (assumed to be /dev/sda3) somewhere, e.g. to /mnt: sudo mount btrfs /dev/sda3 /mnt
2. Optional: list the already existing subvolumes - just check you don't create name conflicts in the following steps: sudo btrfs subvolume list /mnt
3. Clone the main @ subvolume: sudo btrfs subvolume snapshot /mnt/@ /mnt/@trusty
4. Clone the home. I strongly don't recommend sharing the whole home subvolume across different systems. (For shared documents create another subvolume, or even better a separate partition, link it with ~/Documents, ~/Desktop etc. and share that): sudo btrfs subvolume snapshot /mnt/@home /mnt/@trustyhome
5. Edit /mnt/@trusty/etc/fstab on the new root @trusty to reflect the change the @home -> @trustyhome subvolume (and @ -> @trusty, but that step is not strictly necessary, because by the time the system reads @trusty/etc/fstab it must have already assumed the correct subvolume for root).
6. Edit /boot/grub/grub.cfg: modify all lines that call the current kernel (they look like this: linux /vmlinuz-3.16.0-50-generic.efi.signed root=UUID=9e571eab-4c88-4913-baa3-8d41d94f73d5 ro recovery nomodeset rootflags=subvol=@) and change the rootflags=subvol=@ into rootflags=subvol=@trusty, so the kernel knows what to boot. Rather miraculously this setting will be preserved when you do update-grub.
7. Reboot and do sudo mount and verify that the correct new subvolumes are used instead of @ and @home <- This is step is really important, otherwise you will loose your data

And once you renamed the subvolumes, and made sure that system boots, and made sure that there is no @ and @home - install the next OS, with one modification: use a separate /boot partition (800MB should be enough). It helps if your partitions use GPT rather than MBR, which fortunately has became a norm. (To quickly tell if you are using GPT is to see if you boot with UEFI on the motherboard BIOS setup. UEFI works only with partitions set-up in GPT format.

If you don't set up the separate /boot partition - the system will not boot, but you can fix it if you follow the @HullCityFan852 comment:

If you don't have a separate /boot partition then the reboot in Step 7 will fail and you will be left at the grub rescue prompt. At this prompt, type set prefix=($root)/@mint/boot/grub (replace @mint with the path to your distro's subvolume) and then type insmod normal and finally normal to load the Grub menu and boot your distro. Once booted, type sudo update-grub && sudo grub-install to make the change permanent

At the partitioning dialog, use custom partitioning and install the system on the same partition as the first OS. Just be sure, that you tell the installer not to format that partition!

After the installation you can set up chainloading the grubs, so you can select the grub from one installation as an entry on the other and vice versa (how? see What is the recommended way to chainload separate Ubuntu /boot partition).

By having separate /boot partitions I don't have to worry about one Linux messing grub for the other Linux during the automated kernel upgrade.