6

I ran the default install of CEntOS 6.5 on my machine a couple months ago and have since added programs and files which I don't want to get rid of. I'd like to dual boot Ubuntu 14.x and am wondering what to do with the /boot partition. The hard drive is currently partitioned like so:

sda: 256 GB SSD

  • sda1: /boot 500 MB
  • sda2: /LVM physical volume ~237 GB
    • /root
    • /home
    • swap

My question is: Is it OK to share the /boot partition between distros? or do I need to have a separate /boot partition for Ubuntu? If so, is it necessary to put the /boot partition at the beginning of the drive?

2

You can, but it's not a great idea.

In GRUB, what you would do is specify different kernel and initrd files for each distribution installed on the system.

However, the boot configuration for one distro may conflict with the configuration for the other distro(s), depending on how each distro sets its boot configuration and names its files in /boot. This could lead to a messed-up configuration and potentially leave one or more distros unbootable. Special care should be taken when updating the kernel or changing boot settings in any of the distros. If there are no conflicts, however, you should be able to boot both operating systems without issues.

3
  • boot configuration for one distro may conflict with the configuration for the other distro(s)... Not only you can do an upgrade (apt-get dist-upgrade and apt-get autoremove) and erase the file that one distribution can believe not needed any more. – Hastur Nov 3 '15 at 17:41
  • I mentioned that: "Special care should be taken when updating the kernel or changing boot settings in any of the distros." – bwDraco Nov 3 '15 at 17:47
  • I preferred to highlight that even a simple apt-get autoremove can be disruptive. It's possible to miss that with command like the above one (not explicitly related to the kernel) you can erase packages no longer needed for the present distribution included the kernels maybe needed in another... I believe that to listen it more times in different ways it is better than to regret after ;-) See it as a support for your statement "You can, but it's not a great idea." – Hastur Nov 3 '15 at 18:08
2

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.

0

You can have other system directories on different partitions.

To answer your question the best I can. You might be able to share /boot, but it's not recommended. Personally, I don't think it's worth the headache at the end of the day.

1
  • 1
    Welcome to superuser! I would try to answer the question more definitively, and provide some documentation on your answer. – Alex McKenzie Nov 25 '14 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.