There are many youtube videos showing how to install inux on the average PC. There are also many youtube videos showing how to install linux on vmware or virtualbox on the mac. Unfortunately there are only a handful of videos on youtube which show how to install linux directly on mac hardware. Those that do show installation on Mac hardware focus on Ubuntu. This is good for most, but leaves those who would like to try Fedora in the cold. This is also a cop-out because Ubuntu install on Mac is completely painless, for the most part. This page provides the solution to the unique problems which WILL occur when installing Fedora/Chapeau.
Expected errors and pitfalls
This tutorial focuses on getting you through the install. We do not assume to insult your intelligence by walking you through every single step. This tutorial covers pain points. If you follow this tutorial, you will be successful. You should ALWAYS BACK UP your mac files or partition if you have important files you do not want to risk losing.
One-Dimensional installation. -- Trust the Automated installer.
The Fedora /Chapeau, and to a similar degree the Suse installer does not offer sufficient guidance as to what will happen during install. the single most important thing I can say for the install of Fedora or Chapeau on a Macintosh is Trust the automatic partitioning. Rest assured I am am not a newbie. I have been installing linux for almost 20 years, so trust me when I say this. The anaconda installer will select a block of free space and try to install the distribution there.
Mac hardware is very...Finicky. If you try to install Fedora or Chapeau or Suse the traditional way, you will NEVER get it to work. I will get into the reasons for this later. I recommend an External DVD Drive with the installer burned to an ISO. You may of course use other methods such as thumb drives , as you re comfortable. I recommend to avoid unebootin unless you like unneeded complexity.
Use LLVM partitioning. Do not try to manually configure partitions as your years of expertise suggest. It WILL NOT WORK.
LLVM is the only guaranteed way to install Fedora /Chapeau on a modern 64-bit mac with a 64-bit EFI. To make sure you don't try anything silly, the anaconda automatic partitioning Knows you are installing on a mac because it sees the APPLE folder in the EFI directory on the mac side. The automatic partitioning will select LLVM for you. This is a GOOD THING. You can go in and alter suggested sizes but do not switch away from LLVM
Install the Grub boot loader but be aware upon completion and restart, GRUB WILL FAIL. This is to be expected. You can try it without installing a bootloader, but you may not like the results.
After completing installation, and upon restart, you will be taken to a grub screen. Even the normal mac boot screen will be replaced. The OS X Grub entries will not work. The usual Mac Disk Selector that you get when holding down the option key will likely be gone also. You would think that your partitions have been wiped by an installer gone rogue. Do not be afraid. your mac partition is safe.
Reset parameter ram - COMMAND- OPTION + P + R .
This is the ONLY way to get rid of the non-working Grub which has been installed into Apple's EFI directory on SDA . Grub has a few bugs with regards to booting ANY OS X partitions on a mac. Apparently, these will NEVER be fixed.
Once you have done the Parameter ram reset, your mac boot screen will reappear as normal. To get to your Fedora or Chapeau, you must hold down the OPTION key when you start up the mac.
You will then select the Fedora or Chapeau drive. You will then be greeted with the same grub Boot screen from earlier. If you click the 64-bit or 32 bit OSX Partitions, Grub will fail. Don't do it. Just use grub to select your Fedora/Chapeau install. You can find ways to hide Grub or Grub boot entries later and ensure that it only selects your installed distribution once you click the volume in the apple boot selector.
Following these instructions, you have have successfully installed your distribution. You now know how to boot into it and you are reassured that your Mac Partition is safe. You should go ahead and install Refind on the Mac side, or on the Linux side if you want a professional looking boot-up and OS selection. There are many beautiful Refind themes available.
The artist who wrote this article is quite literally starving. if you like this article, send bitcoin.
Grub bug on mac: https://bugzilla.redhat.com/show_bug.cgi?id=893179
There is fierce debate brewing in the Linux community right now. Here we have two rival formats for packaging software. which one will be victorious and become the standard across all Linux desktops ? The answer in our opinion is that both will find a strong following for various reasons. Both will serve the common user, but one will reign supreme for industrial use. From as security viewpoint, at least for now, Flatpak has the advantage.
A brief history of software packages
A package is a piece of software that can simply be downloaded and run without the need to compile. “Hello world”, the first program taught in computer programming classes, is technically a package once it has been compiled. Packages are generally built on the assumption that all the necessary files and libraries need to run the software are installed on the operating system. GNU/Linux packages are either based upon Red Hat's RPM format or the Debian package format known as .RPM and .DEB respectively. There are some distributions that use tar.gz packages, but those will not be mentioned in this article.
During the mid 1990’s as Red Hat started becoming popular, users noticed that there was often difficulty in installing .rpm files. They experienced what is still known as “RPM Hell.” This term describes the situation where an RPM package cannot be installed for a number of reasons Generally, there are files missing or in the wrong version, preventing the RPM file from being installed. Users later found solace in the Debian package format which did not have this issue to the same extent. Debian relies upon repositories that contain all of the needed files The Debian system was built on the assumption that whatever packages were needed could be downloaded from somewhere in the Debian universe of repositories. Debian GNU/Linux distributions have the APT package management tool which solves dependency issues by downloading the required files and even compiling from source if needed. The RPM package manager tries to do the same thing but is not as effective as the Debian system. Red Hat tried to adapt to a repository based system but has not achieved the ubiquity of Debian-based repository system. As Debian became more popular it started being spun out into different derivative distributions such as Mint, Parsix, Elementary OS, Deepin, and numerous others, conflicts reminiscent of RPM hell are starting to become more common in the Debian world. There are only a literal handful of Red Hat derivative distributions as of the time of the writing of this article. Many believe that the primary reason for this is Debian’s superior package management. In the interest of fairness, the term “RPM Hell” has been expanded to the more proper and universal “dependency hell.” Also in the interest of fairness, it should be noted that Red Hat’s package management system has improved and does a much better job of using repositories. The problem of dependency hell still exists as of the time of the writing of this article.
Attempts were made to standardize the packages found in major distributions, in hopes of eliminating dependency issues. One such effort was the Linux Standard base. Because of the large variety of GNU/Linux distributions and derivative distributions, LSB failed in achieving this particular goal.
Over the course of time, Red Hat engineers and the Fedora community determined that they needed a package format which could compete with Debian and also prevent RPM hell from continuing. Ubuntu, a major GNU/Linux distribution, developed a package system which enabled packages written for their mobile phone operating system to be easily installed on any Ubuntu-based desktop operating systems. As a result of the transactional nature of Snappy packages, Ubuntu inadvertently developed Snappy, a package format which contains all of the needed files and binaries. Ubuntu developed what many believe to be the holy grail of package management. Ubuntu’s snappy packages could install on any GNU/Linux distribution, past, present, or future, as long as snapd was running. While Ubuntu was developing Snappy, Red Hat, along with Gnome desktop developers were developing Flatpak. Flatpak works on a very similar concept to Snappy packages. Flatpak requires Gnome desktop packages and the Flatpak executable, while Snappy requires only snapd, Ubuntu’s package installation daemon. Both Snappy and Flatpak applications can install and run on virtually any GNU/Linux distribution meeting these requirements. As is the nature of open source, several other universal types of packages are coming into existence. In the interest of brevity, those will not be discussed in this article. The market is expected to coalesce around Snappy and Flatpak.
The question of security
On the surface, it would seem that all would be well in the Linux community now that two excellent package formats have arrived. The truth is, that as of the time of this writing, there is a more complicated issue which has to be resolved. This issue is security. Red Hat developed a super-secure GNU/Linux Kernel module called SELinux In this system nothing happens without the user knowing. Access to every system function and file can be precisely controlled by the system administrator. When Ubuntu was developing Snappy, they developed around the Ubuntu system, which does not use SELinux. Ubuntu believes that all the security should be in the package itself. Snappy was developed based on an insecure Kernel and also on the insecure X11display server (Graphics system). Since SELinux requires that all systems be secure, SELinux would need to be turned off in order for snappy packages to install and run. Flatpak , on the other hand was built from the ground up to work with various security protocols and is extensible to any other security protocol that comes into use. Flatpak will also work with insecure GNU/Linux systems and, like snappy, has sandboxing and signed binaries, which does offer a form of security. Snappy does use Apparmor security protocol. The question for some is “ Is snappy secure enough?” The answer for most desktop users is that Snappy has sufficient security for most uses. For the enterprise, the difference is stark. Granular security is top-priority. How will this issue be resolved ? Most likely what will happen is that Ubuntu will try to update snapd to understand packages that have an added security layer which can interface with various security systems, including Apparmor and forthcoming secure display servers such as Wayland and Mir. This may be difficult to do since snappy is designed to work with a wide range of operating systems on various different types of devices. Some devices will be too small and low-powered to be able to handle the additional requirements that supporting various security protocols will require. So we have two different package systems, both of which are superior to the other in different ways. Red Hat finally has an advantage over the Debian world. How long will that advantage last, it is hard to say. Considering the resources that Ubuntu has used to develop their system the way it is, likely a very long time.
The question of distribution
Snappy works off of a concept similar to Apple's "App Store" Canonical is quite correct in referring to their approach as "transactional" Without Canonical's store, or some other Snappy server set up specifically to distribute your application, snappy may not work as you might expect. Flatpak on the other hand does not require a server of any kind. Your Flatpak file is fully independent and self-contained at all times. There is no app store unless the person distributing the app chooses to implement a transaction-based system.
A scandal is brewing
As of the time of this writing, it should be noted that there is somewhat of a scandal concerning the way in which Canonical has deceitfully marketed their Snappy package management system. For further info please consult:
Also: Great thanks to the author of the above-mentioned article for technical and chronological info will be used to correct any technical and/or historical shortcomings of this article.
Articles in agreement
Canonical has marketing muscle and large corporate partners. they have a soapbox for their point of view. This article is written for the contrarian view. as a result of this, there will be a section periodically updated with articles in agreement with our viewpoint.