Spiria logo.

Setting up an octo-boot on a Mac (part 1)

February 6, 2020.

Background

As a hands-on IT director in a mid-sized company like mine, I have to come to terms with the fact that some users are bound to use Apple products and that they are most likely going to end up asking for our help. Given this fact, we need to have a fairly recent device with macOS installed on it in order to run tests or troubleshooting tasks, but the last time I checked, Apple licensing terms required that we run macOS from an official Apple product. Recently, I recovered a MacBook Pro 2015 from a free repair for a battery problem. Given our internal policy that requires that we replace equipment every five years, I asked my boss if I could replace the internal drive of the Pro to obtain a triple boot machine for IT purposes (macOS, Microsoft and Linux). He agreed to the purchase, as long as I produced some blog articles on my experience.

But then, I started thinking. Why not four operating systems? And since I was sleep-deprived that day, things snowballed from there, and I ended up talking myself into having eight operating systems, because “octuple” sounds cooler and more recognizable than nonuple or septuple. So, here we go.

Disclaimer! Playing with the partitions, especially the boot partition, is not something for the faint of heart; it can even make your device permanently unbootable. Do not do this unless you are familiar with things such as disk partitions, GRUB, EFI, etc.

Even more important warning!!! IT people talk to themselves... a lot... We pretend it’s a process, but in fact, we’re just sleep-deprived wrecks.

The basics

Octo-boot.

Broad project strokes

Officially, Apple supports dual booting for macOS and Windows through Boot Camp, and the procedure is pretty straightforward. However, when it comes to triple booting with a Linux distribution, things start to get hairy. Those who do that sort of thing recommend using a boot manager called “rEFInd”. It has to be installed manually from a USB key during the process. I had a list of Linux distributions I wanted to install, but I had to change it a little along the way. At the time of writing, I basically achieved my goal of having eight distributions on the same device with the help of an excellent article I found here.

The operating systems

Along with Windows and macOS, we installed a series of Linux distributions (or distro in geek speak). Linux is the central program, called kernel, to which a series of tools and programs are attached (desktop environment, file systems, libraries, etc.) in order to make a complete operating system.

Here is the list of OSs I ended up installing, with partition sizes and reason for installation:

  • macOS
    • Size: 256 GB.
    • OS: Duh ... (and FreeBSD-based).
    • Reason: take one for the team and test forecasted enterprise management tools.
  • Windows 10 Pro
    • Size: 256 GB split across C: drive for OS and D: drive to be shared across OSs.
    • Desktop: MS Windows.
    • Reason: to run Crysis.
  • Linux Mint
    • Size: 64 GB.
    • Desktop: Cinnamon Desktop, Ubuntu(ish)-based.
    • Reason: LinuxMint is usually my “go-to” distribution for desktop implementation and since I am quite familiar with it, it is also my “control” in this experiment.
  • Suse Linux
    • Notes:
      • I intended to use a Gentoo-based distro, but they are notorious for being hard to use and more geared toward servers. Sabayon would not even start the install process, and Redcore could not get Wi-Fi to work (and repositories were-based in Russia).
      • I switched to Suse Linux because its main development base is in Germany and everyone knows that everything German is well-engineered (and cool).
    • Size: 64 GB.
    • Desktop: KDE Plasma, Slackware(ish)-based.
    • Reason: Deutschland!!! Testing out the Btrfs file system.
  • Manjaro
    • Size: 64 GB.
    • Desktop: KDE, ArchLinux-based.
    • Reason: Arch-based repo experimentation (Pacman).
  • Fedora
    • Size: 64 GB.
    • Desktop: Mate Desktop, Redhat-based.
    • Reason: RedHat-based distro is one of the biggest Linux distributions and uses YUM repo management.
  • Kali Linux
    • Size: 128 GB.
    • Desktop: GNOME Desktop, Debian-based.
    • Reason: security testing. This distribution is preloaded with a wide array of security tools for ethical hacking.
  • Ubuntu Studio
    • Size: 128 GB.
    • Desktop: XFCE, Ubuntu-based, with allegedly low-latency kernel.
    • Reason: to have some distro geared toward artsy-fartsy stuff and test the low-latency kernel feature if possible.

Post-installation goals

The subsequent goals are as follows:

  • Test a variety of desktop distributions and desktop UI:
    • Linux distributions are (in)famous for their flexibility.
    • This can make support somewhat difficult and spotty in some cases due to the wide variety of hardware available.
    • On any given distribution, you can have a wide array of Windows Management UI.
    • I tried to pick the widest possible assortment of desktop software and pick those that came “out of the box” when installing the distro.
      • You can usually pick any desktop of your choosing after installing the “default” desktop.
      • I chose to pick those that were “officially” supported during install time to reduce problems.
  • Have a shared disk drive partition across all OSs:
    • I usually do that with any dual boot machine that I run, in order to facilitate access to various files such as photos, music files, video, etc.
    • Since Windows traditionally never supported File Systems other than FAT and NTFS, I always shared a “D” drive formatted as NTFS.
  • Have the following tested and working:
    • Webcam;
    • SD card slot;
    • External display;
    • Power management;
    • Special functions;
      • Through combos of Control, Option and Command keys, you can control various aspects of the device, such as brightness and volume.
      • All functionalities should be available throughout all OSs.
    • USB external headset;
    • 3.5 external headset;
    • Wired NIC;
    • Wi-Fi network;
    • USB-based external enclosure.
  • Test various applications and workloads:
    • Firefox browser.
      • Find a demanding application/website and get stats.
    • Chrome Browser.
      • Install and run the official Google version.
    • Filesystem.
      • File copy.
      • Zipping in NTFS and in base-FS of each OS.
      • Document base-FS in each.
    • A/V-crunching software.
      • Find a tool that can be used across platforms to convert video/audio files to another format in order to compare performance.
    • Compilation tool.
      • To be determined. Ideally, a cross-platform tool and something to crunch that is big enough to take at least five minutes under macOS.
      • I will get my colleagues to help me with that.
    • Wi-Fi/wired - download/latency.
      • Find a tool that can be used across OSs and provide a variety of statistics.
    • 3d rendering tool.
      • Test on Blender.

Hardware and initial installation

The Mac Pro 2015 disk is relatively easy to access and replace as long as you have the right tools. I will not go into details here but be warned that the screws are of the type called “pentalobe” and that they are easily stripped. I ordered a NVMe disk from OWC because I expect that a regular NVMe disk will not work as intended, something I will test out at the end of the project. My first (semi) surprise was to find a Samsung NVMe disk inside an Apple laptop. It shows that while the two are at odds in public, they get together under the covers in private. The reinstallation of the macOS software and the subsequent Windows install through Boot Camp went pretty much without a hitch. I will not go through the whole process here, since it is amply covered in many other articles out there.

Samsung S4LN058A01-8030.

Samsung’s NVMe SSD.

The fun really begins with the Linux install. Basically, whenever you install a Linux distribution, it installs GRUB (except for SuSe), which causes macOS to stop booting while everything else still works. The workaround I found was to reinstall rEFInd every time, but then I realized that I would also need to reinstall the rEFInd application every time a Linux distribution got a new kernel in its upgrade. I tried to find a workaround for that by manually editing the GRUB file with some changes suggested by various forums, to no avail. This will require some digging. Another problem I ran into was that Windows would not start either, and I had to disable the System Integrity Protection (SIP).

Aside from those little annoyances, I was very surprised to find that the Wi-Fi pretty much worked out of the box on all distros that I ended up installing. This had been my biggest concern. Wi-Fi drivers are usually the most contentious part of a Linux distribution installation, given that Wi-Fi chips are often welded to closed-source drivers.

The biggest problem I had was the laptop display experience, which proved to be somewhat uneven. Some worked right away, while others required some tweaks. All had a few bugs here and there due to the fact that this specific laptop model has a Retina display. It’s very nice looking, but it needs some adjustments in order to be usable. Usually, the problems were (mostly) resolved by googling HiDPi settings for the various platforms. In the end, the only irritant that remained was in the boot login manager of the GRUB screen, which I will research later.

What now?

Somewhere in the process, I got a little carried away and forgot to take notes about the desktop UI adjustments. I think I will just re-run the installation procedures and write down the details for each distro in part 2 or 3 of this blog article. I need to do some research on the GRUB situation to see if I can do something about it or if I am just going to have to stick to “rEFInd”. As previously mentioned, playing with the bootloader is somewhat risky and the documentation on the subject is sparse. Whenever I found an article about it, there was always a caveat. Ideally, I would like to have GRUB as my permanent boot loader and have it running permanently and consistently throughout Linux kernel upgrades. Plan B would be to remove the default GRUB installation, since rEFInd can detect new OSs quite nicely.