Installing Linux Multi-Boot Using rEFInd - Neither USB nor DVD Installers Boot

If the GPU on your Mac has a problem (very common with those 2008 - 2011 MBPro 15" models), then it may prevent Linux from booting even if macOS was seemingly working fine....some of those GPU issues would show up in very odd unexpected ways.

Sometimes the Linux boot disks will have issues booting due to Linux Kernel configurations & kernel boot settings (on a standard Windows' based non-Apple PC). With Macs, things can be even a bit more complicated due to the Mac's firmware where you may not always see the early boot screen when booting Linux (it varies).

I don't know anything specific regarding any of the Linux distributions you have listed. Some of them may actually have issues booting on a Mac. Usually Linux Mint is usually Ok as a co-worker tends to use it for older Macs. Ubuntu is probably Ok as well. Generally. However, Ubuntu has been known to have odd boot issues from time to time. I would suggest focusing on Ubuntu or Linux Mint at the moment & check their forums and other online resources to see if there are any current boot issues in general and also Mac specific.

Sometimes you need to modify the Linux kernel boot options related to video, and possibly power management. I cannot remember some of the others I have used. You can easily add these kernel options by press "E" when the GRUB menu is shown on the screen to "edit" the boot options. Scroll down until you see the main entry and add on a boot option, then select the option to boot (I believe it may be F10, but there may be another key that can be used as well....it has been a while since I did this).

nomodeset
noapic
acpi=off

Make sure to use either "dd" or Etcher (Mac, Windows, Linux) when making the bootable Linux USB installer. Other methods (UNetBootin especially) may make some modifications to the actual USB installer. Also, use Option Boot to boot the USB installer just to be 100% sure that rEFInd is not complicating things. I know rEFInd is very good and probably is not causing any problems with the Linux USB installers, but best to test with Mac only options to simplify troubleshooting.

Once you can get Ubuntu or Linux Mint installers working, then you can try the other distributions. You will find more online help for Ubuntu & Linux Mint (especially on Macs) than any of the others. Most likely the fix is the same for all distributions, but each distribution may do things a bit differently or have other things that may interfere with troubleshooting.

You may also want to try a much older Ubuntu or Linux Mint installer from many years ago to see if that works.

Try booting from a Knoppix Linux USB stick. You can try a recent version, but again you may want to try a much older one to compare. I'm not sure how far back you can go since most mirrors tend to remove the older ones (version 6.x or 7.x would be Ok, but use whatever is available...if v8.x then go with v8.6.1). With Knoppix you will need to give Knoppix lots of time to boot due to the previously mentioned Mac firmware issues since the Mac may appear to be frozen on the Apple boot picker menu. Knoppix boots just about any Intel system out there and if it has trouble activating the graphical interface, then it will drop you into a command prompt where you can look at the system boot logs to see what may have prevented booting into a GUI. Most likely it will be a bad GPU....that is the only reason I've ever seen Knoppix fail to boot into a GUI on a Mac. It is possible that using rEFInd to boot Knoppix may allow you to see the earlier Knoppix boot screens. Don't use Knoppix as a daily driver though since it is highly customized even though it has an "install" option....it is great for test booting systems though.

FYI, SIP has nothing to do with booting Linux.

Edit: Modifying the Linux kernel boot options through the GRUB menu as I mentioned is a one time option & does not save the changes.

You do need to use Disk Utility in macOS to create a partition for the Linux installation. When you boot the Linux installer, then you will delete that partition so you can use its space for the various Linux partitions the Linux installer will create. Linux cannot and should not be used to modify a macOS or Windows system. On a multi-boot system Linux should only delete or modify the partition(s) Linux will use.

Here is forum post which shows a few options when Ubuntu boots to a black screen (see #2 for the installer, and see #3 black/purple screen where it shows how to modify the Linux kernel boot option using the GRUB menu during boot):

https://askubuntu.com/a/162076

Keep in mind that Linux Mint & PopOS are both based on Ubuntu, but have been heavily modified although the Linux kernel & boot process are likely nearly identical. You can add multiple Linux kernel options. You can also remove the "quiet" option and add "text" which may display the installer's boot log on screen so it may help you to figure out what happens. You may need to search for the proper kernel boot option to enable showing the boot log on screen during Linux boot. It has been a while since I modified any Linux boot options.

Also, don't worry about what the installers are like since many times they don't receive any love. It is how the full Linux installation looks & functions that is important, and how you may upgrade to a new major version.

Most Linux distributions are basically the same. The Linux kernel is basically the same although some distributions may enable or disable some options....probably not a big deal. The graphical interface will differ depending on the Desktop Environment used. Most distributions have multiple Desktop Environments to choose from and can usually be selected during installation (may need the advanced options/mode). Desktop Environments typically have certain default apps associated with them....some may share them with other Desktop Environments). Don't let that deter you from any specific distribution.

In the early days of Linux I tried many different distributions (they were a lot more varied back then with many different package managers). However, if you want a long term Linux installation, then stick with a distribution with a history of sticking around.

You should install rEFInd after installing macOS since some Linux distributions may not be seen as bootable by the Mac once installed due to the Mac's firmware possibly requiring the Linux bootloader to being named a generic "boot/boot_x64.efi" instead of "ubuntu/grub_x64.efi". Many PCs are the same way although I believe more recent PCs are better at being able to use customized names.

As for "/boot/efi" errors, that may be due to the EFI (aka ESP) partition not being mounted. Some distributions may not mount the EFI/ESP partition automatically. Kind of like a safety/security feature.

Again, the version of macOS installed on the drive doesn't matter and has no affect for installing & booting Linux. Any issues booting the Linux installer or a full Linux installation is due to Linux bootloader, configuration & driver issues. It may be due to Apple hardware issues (chipsets used, or bad hardware like the GPU), or it may just be Intel or NVidia chipset issues in general. The Linux kernel has had a lot of changes since 2008 and while it should still work perfectly fine on a 2008 system, it is possible some of the kernel changes have negatively affected some older systems.

g_wolfman wrote:

Thanks, got it working. Basically came down to a couple of things, I think...I ended up having to create small boot partitions for each Linux to mount as /boot/efi to keep them from trashing each other on the main disk device EFI partition (I'm guessing because they are both Ubuntu variants and write grub_x64.efi files).

For the most part I just use Debian so I'm not sure what some of the derivative distributions do. I know some of them use their own name for the bootloader folder on the EFI/ESP partition, but some may just be lazy & default to the parent name such as "ubuntu", or possibly using the generic "boot" so it is guaranteed to be compatible with all systems.

You can easily change the folder name on the EFI/ESP partition....no need to change the "grub_x64.efi" name. The only downside is if the Linux installation decides to update the bootloader (doubtful, but always a possibility) especially if you are just testing various distributions until you find your best match. To make the change properly, you would need to modify the GRUB configuration file.

And for some reason I did not dig too deeply into yet, I ended up having to manually install the rEFInd files.

Nothing wrong with that since the installer shell script basically just creates a "refind" folder on the EFI/ESP partition and blesses it so that the PRAM will default to booting rEFInd. It is one of the things I like about rEFInd.

The Pop! OS issue was just a bad choice on my part. The version without modern NVIDIA drivers pre-compiled booted up just fine.

NVidia GPUs are complicated. Until recently you had to use a basic video driver or use the official proprietary NVidia drivers if your computer had an NVidia GPU (different Linux distributions handled the proprietary NVidia driver differently). About a year ago, NVidia finally started to release support for the GSP firmware so that the Linux open source GPU drivers can work properly with NVidia video cards. Prior to this NVidia's GPU firmware did not allow reclocking the GPU so that Linux drivers could not properly set the GPU clocking speed. Unfortunately I think this only applies to more recent NVidia GPUs and probably not one from 2008.

I stopped following NVidia many years ago when they cheated on the GPU benchmark tests and released very misleading video cards, plus once AMD started releasing their GPU drivers as open source I lost interest in NVidia since the NVidia proprietary GPU drivers while very good, were a pain to use with Linux since it required updating the kernel modules every time the Linux kernel was patched or upgraded (among other things).

Here is an old article from 2017 about the way NVidia refused to help the Linux community in providing the ability to reclock the NVidia GPU:

https://www.phoronix.com/news/Nouveau-XDC2017

NVidia begins releasing some GPU documentation to the open source community in 2019:

https://www.phoronix.com/news/NVIDIA-Open-GPU-Docs

It took until 2023 before NVidia provided any assistance to the Linux community to allow GPU reclocking for the more recent NVidia GPUs (I cannot find the first announcement, but here is an article about one of the first patches submitted to the Linux kernel to help with the open source NVidia driver support on Linux:

https://www.phoronix.com/news/Nouveau-GSP-Merged-Linux-6.7

While I really loved the NVidia GPUs & drivers back in the day (for Win95 to WinXP) since at the time ATI GPU drivers were really bad especially for gaming....NVidia broke my trust and will likely never win it back especially since AMD actively provides open source drivers for their AMD GPUs (AMD acquired ATI many years ago and AMD has shown some love to the open source community) which really says something. It doesn't hurt that they make great CPUs as well.

My guess is you might have better luck on the rEFInd forums.

Continued...

There was still something there that was a bit wonky when I turned on Filevault (had to reinstall rEFInd at that point, and then manually bless the refind_x64.efi file). Probably just something not liking what the Core Storage conversion did to the partition table, I'm guessing.

It is probably because enabling Filevault changes the identify of the volume being encrypted, so the bootloader needs to be updated for that change. The same thing would occur if you turn Filevault off.

Now I just have to figure out the best way to customize the OS Icons and labels in rEFInd...gotta say, for something written by a technical writer, the rEFInd manual is not easy to parse in many places.

I haven't used rEFInd in a long time and even when I did use it I don't think I ever customized it. It really should not be too hard. You probably only need to know the file types, resolutions, & color depths allowed.

Technical documentation is very difficult. Probably some of it also has to do with getting bored by it as well...it really isn't very exciting. People usually are just satisfied with getting something to work & slightly documenting the process.

Anyway, thanks for the insights - very useful.

You're welcome.

Just know that research & experimentation is required while also being able to discern which tidbits are to be avoided. Within Linux, there are usually dozens of ways to accomplish a task. Some will technically get the job done, but should be avoided at all costs....while others may be more difficult to understand & implement, but they are the best way to do it......and you will have a lot scattered between the two extremes. Never take the first thing you find....and read all the comments since they usually contain important tidbits of wisdom for why one option may be better or worse than another.

g_wolfman wrote:

I'll play with grub.cfg to update-proof that later.

I don't think you want to touch that file since an OS update patch could change it. Read up on how to customize GRUB2. I think you need to add or modify files within the "grub.d" folder. I only ever dabbled with customizing GRUB configuration....it is a bit confusing....I never really did get the hang of it to do it properly.

VirtualBox or VMWare or UTM offer Linux installation capability. I would research each program and figure out which is easiest. I don't believe Boot Camp itself can do it.