Can I have two distros on the same partition using btrfs?
I'm using btrfs successfully and have luckily separate home and system partitions.
Using Ubuntu 13.10 and wanting to test 14.04, how can I do this using the btrfs file system?
The system has an EFI partition, but no extra boot partition. /boot
is inside the system partition (/@/boot
).
Solution 1:
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:
- mount root subvolume of the system btrfs partition (assumed to be /dev/sda3) somewhere, e.g. to /mnt:
sudo mount btrfs /dev/sda3 /mnt
- Optional: list the already existing subvolumes - just check you don't create name conflicts in the following steps:
sudo btrfs subvolume list /mnt
- Clone the main @ subvolume:
sudo btrfs subvolume snapshot /mnt/@ /mnt/@trusty
- 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
- 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). - 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 therootflags=subvol=@
intorootflags=subvol=@trusty
, so the kernel knows what to boot. Rather miraculously this setting will be preserved when you doupdate-grub
. - 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 typeinsmod normal
and finallynormal
to load the Grub menu and boot your distro. Once booted, typesudo 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.