I realize this is a bit late to the party, but I just took this on to keep three concurrent installations and one /boot
partition:
- arch linux
- ubuntu 14.04
- ubuntu 16.04
I've used arch for years, but was quite unfamiliar with ubuntu and wasn't sure how to stop it from installing a bootloader so I just let it. For arch, I've been using syslinux
, not grub
so I'm a lot more familiar with it. While this is somewhat early in my experiment, here's my procedure:
- identify the potentially conflicting files. After noting the naming conventions of ubuntu vs. arch, this came down to 14.04 and 16.04's
vmlinuz
and ininrd.img
, which are named the same (maybe aside from version number if they update at different times). For all I know they are compatible, but I opted to treat them as not.
- setup
syslinux
as usual, creating entries for each distro (shown below)
- upon update of either of the potentially conflicting distros, implement a naming strategy to avoid issues
- have a backup plan
If either ubuntu updates the kernel, I get two key files:
/boot/initrd.img-x.x.x-xx-generic
/boot/vmlinuz-x.x.x-xx-generic
For each of the above, I simply append _distro
to the end, as well as replace a statically named variant to keep from changing my syslinux.cfg
each update (more shown below). The process would look like this, using 14.04/Trusty as the example and only showing the files of interest.
$ cd /boot
$ sudo mv ./initrd.img-4.4.0-62-generic ./initrd.img-4.4.0-62-generic_trusty
$ sudo cp ./initrd.img-4.4.0-62-generic_trusty ./initrd-trusty.img
$ sudo mv ./vmlinuz-4.4.0-62-generic ./vmlinuz-4.4.0-62-generic_trusty
$ sudo cp ./vmlinuz-4.4.0-62-generic_trusty vmlinuz-trusty
Since arch's naming convention never conflicts, this means I end up with 2 backup/accurately named initrd
and vmlinuz
files along with two that I can use to keep from changing my syslinux.cfg
all the time. The key files are like so (with comments added):
$ ls /boot/
initramfs-linux.img ## arch main initramfs
initramfs-linux-fallback.img ## arch fallback initramfs
initrd.img-4.4.0-62-generic_trusty ## named recent 14.04 initrd
initrd.img-4.4.0-62-generic_xenial ## same for xenial (16.04)
initrd-trusty.img ## statically named initrd
initrd-xenial.img
vmlinuz-4.4.0-62-generic_trusty ## named vmlinuz
vmlinuz-4.4.0-62-generic_xenial
vmlinuz-linux ## arch's vmlinuz
vmlinuz-trusty ## statically named vmlinuz
vmlinuz-xenial
For booting, here's my syslinux
entries:
LABEL arch
MENU LABEL arch
LINUX ../vmlinuz-linux
APPEND luks-options-here rootflags=compress=lzo,discard,ssd,subvol=arch rw
INITRD ../intel-ucode.img,../initramfs-linux.img
LABEL xenial
MENU LABEL xenial
LINUX ../vmlinuz-xenial
APPEND luks-options-here ro rootflags=compress=lzo,discard,ssd,subvol=xenial quiet splash $vt_handoff
INITRD ../initrd-xenial.img
LABEL trusty
MENU LABEL trusty
LINUX ../vmlinuz-trusty
APPEND luks-options-here ro rootflags=compress=lzo,discard,ssd,subvol=trusty quiet $vt_handoff
INITRD ../initrd-trusty.img
So far I've left grub
on the ubuntus and it complains at each update but nothing has gone awry. My backup plan was to copy mbr.bin
to /boot/
(usually it resides in /usr/lib/syslinux...
on arch) so that if grub
decides to overwrite my bootloader I can at least dd
the syslinux
bootloader back. I'm 95%+ confident that my arch install will never get borked (at least to boot), so I'll almost always be able to boot to that and fix the ubuntus if I copied/named something incorrectly. Likely I'll keep one former version of each initrd/vmlinuz
around so that I can change which one is loaded at boot in case something goes wrong with the initramfs
process.
Hopefully that's relatively clear what's going on. I could probably use links, some sort of post-update script, etc. to automate but haven't gotten there yet.
The accepted answer reveals that things could go wrong, but since I googled around for examples of others doing this, and only found answers like this (basically, "possible, but don't") I figured I'd add a tangible example of how one could set something like this up.
Personally, I'm quite excited about it. I have one boot partition and as you might have noticed, three side-by-side distros on one btrfs
partition. No need to pre-allocate sizes, no worries about disliking one setup and blowing it away (getting left with an un-used partition floating around) and no need for a bunch of logical volumes just to boot a linux partition when I already have a bootloader!
Hope this helps someone.