I have a Macbook Pro and I am loving it, though I still miss my Linux box, there are many things I need which are not completely compatible with Mac OS X.
I heard many stories about installing Linux on a Mac OS, some say it’s not a problem, but some others tend to say differently.
My question is, is it or is not fine to install Linux on a Mac OS machine? What are the pros and cons?
I am very well aware about virtual machines, but let’s be honest, they do not run quite as well when running on a physical hardware.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
tl;dr: it’s doable but you will have to work just a little bit. If you don’t have the ability to use Ethernet, and are installing from netinst media, you’re basically screwed (although if you’re really determined you can make it work).
When I originally wrote this answer, I’d only done this once, but now I’m doing it again on a different Mac, so I’ve split the post into two.
Debian Jessie on a MacBook Pro
I have successfully installed Debian Jessie (currently aka Debian Testing) on my MacBook Pro, early 2011.
I’m going to say this right away: If you have a MacBook Air and/or no Ethernet cord, you are largely screwed if you use a distro that uses a network-based installation (such as Arch Linux, or the recommended Debian image, or one of the Ubuntu alternate CDs). You will basically have to download all the firmware files, boot the installation media in such a way that it is prevented from doing network configuration, install the firmware manually, and then try to get it to pick up the firmware. Then have it do network configuration. To be perfectly honest, I never got that to work and am not entirely sure that it’s a sound plan.
Other than that, installation went smoothly. If you intend to keep OS X, you should use OS X’s built-in Disk Utility to resize, as GNU/Linux doesn’t currently have write support for the default Mac filesystem configuration (HFS+ with journaling, for those curious; write support only works without journaling). Note that you don’t have to boot into the Recovery partition to do this – HFS+ can do online resizing – but you may see Disk Utility or your entire computer freeze. Don’t worry, this has happened to me a couple of times and you just have to let it do its thing, but you won’t be able to use the Mac while the process is taking place. I have heard that Disk Utility has bugs when creating an empty partition (which you will have to do for Disk Utility to let you resize). Therefore, I’d recommend creating a FAT filesystem on the new partition. You’re welcome to try with the “none” option selected, but I played it safe.
Since I used the Debian Installer, I’m not really sure how it installed GRUB (I’m going to replace Debian with Arch soon, so I’ll edit this answer with my results). It appears to have installed to the EFI partition in the Mac, but I’m not sure if it did any magic aside from that. Presumably not, but who knows. After installing GRUB, you need to reboot into Mac OS X. Open a terminal, mount the EFI partition (use diskutil list to dump information about disks; it’s like OS X’s version of blkid or lsblk), and muck around with the bless utility until you get to the GRUB menu on reboot. (I don’t know exact steps for this, because I tried a bunch of things at the same time because I didn’t want to wait through OS X’s long reboot time). See man bless in OS X for the details of this utility.
Note that yes, upon success you will go directly to the GRUB boot menu (assuming you’re using GRUB). I’m not sure the internals of how it works, especially with Apple’s moon-man EFI implementation, but here’s how you choose the OS to boot from:
- If you want GNU/Linux, do nothing. The GRUB boot menu will appear (again, assuming you’re using GRUB).
- If you want Mac OS X, wait for the startup tone, then hold Option until you get the disk chooser menu. Two disk options should appear: Macintosh HD and EFI Boot. Select Macintosh HD. Note: the Mac OS X option in GRUB appears to do nothing but hang.
- If you want Mac OS X Recovery, wait for the startup tone, then hold Option until you get the disk chooser menu. It’s the exact same thing as booting regular OS X, except you choose EFI Boot instead of Macintosh HD.
The touchpad driver in Xorg is extremely lacking. Xorg will choose the Synaptics driver for you, which is a piece of crap on an Apple touchpad. Therefore, Google around until you find a decent driver, then override the Synaptics driver with it in your xorg.conf (or xorg.conf.d, depending on distro), although I never could find a driver that could actually do right-click on the Apple trackpad, which is kind of a pain in the neck. I would tell you the exact details of my configuration, but I have an initial Time Machine backup running and can’t be bothered to reboot into Debian. I’ll edit this answer when I do, though.
The biggest thing besides the wireless (which needs firmware but is easy to bootstrap as long as you have an Ethernet cable) was that if I closed the lid, the screen failed to wake up. The keyboard backlight would turn on, but never the screen. Preliminary Googling says that this is a kernel bug, but I haven’t looked into exact fixes. I’ve started experimenting with the pm-* family of utilities (e.g. pm-suspend) but haven’t done anything in-depth. A workaround for this issue is to switch to a virtual console, to “defocus” Xorg. This way, when you close the lid, your computer won’t try to suspend at all. Note that this means that the Apple logo on the back will continue to be lit, although turning down the screen brightness also affects the Apple logo. Note, though, that you can only use the function keys when Xorg is “focused”. Which brings me neatly to my next topic…
The keyboard basically acts normally. Option works exactly as you would expect alt to. Command is the superkey. The only thing that tripped me up – although not for long – is that the function keys not needing Fn pressed is a hardware thing, not a software thing. Therefore pressing e.g. brightness up works the same as in OS X – when you press F2, it turns up the brightness, and when you press Fn+F2, it sends the F2 key.
The final thing that I should mention is that I never got 3D acceleration to work. The GLX Gears demo worked with (I think) mesa, but I got booted to GNOME Fallback, so clearly true acceleration isn’t working. The solution that I found hung me at boot (see the last post about the Debian installation in my blog), so I don’t think there actually is a solution, at least until the linux-firmware-nonfree package is split up even more.
If you’re interested in all the gory details, you should read my blog posts on the matter (just click next until you reach the one called “I FIXED EVERYTHING”). They also probably mention some details that I can’t remember off the top of my head (like the name of that touchpad driver!).
Arch Linux (September 2013 image) on an iMac
I allocated space for the Arch install from OS X (see the beginning of the Debian section for the reasoning behind this), creating a ~100 GB partition for /home and ~100GB partition for /.
The CD boots fine – just hold down option, and then select the CD icon labelled “EFI Boot”. The keyboard works fine up until you hit enter on the “boot Arch” option, at which point presumably Arch takes over from EFI, and hence the EFI Bluetooth keyboard driver. Therefore you’ll need a USB keyboard to actually go through the installation.
The first thing I did after booting was to connect to the internet with wifi-menu, which surprisingly worked without a hitch. Next I messed with the sizing of the partitions that I’d allocated for Arch using cgdisk, since I’d changed my mind – this is apparently OK and I was able to reboot into OS X without a problem. One problem that I ran into is that I made a partition too small, and wanted to cut into the OS X partition to expand it. However, when I went to Disk Utility to shrink the OS X partition, it said “preparing to partition…” and then never got any further. Tried doing it from the recovery partition (with Macintosh HD both mounted and unmounted): same result. So the moral of the story is: be sure about your partition layout before you install!
From then on the install went without a problem. When I got to bootloader installation, I installed the grub, efibootmgr and dosfstools packages from Arch, as recommended by the wiki. I additionally installed os-prober, although according to the package description this is only for BIOS systems. I mounted the EFI system partition on /boot/efi (following the wiki, I’ll refer to this as $esp below). Note that (at least on my computer) the EFI system partition is the first partition, making it /dev/sda1 under GNU/Linux and /dev/disk0s1 under OS X/Darwin. I installed GRUB using the following command:
grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug
If you can’t be bothered to look, this is pretty much verbatim what the wiki recommends for the easy install (not keeping everything in the EFI partition, so some stuff goes in /boot). At the end it said “EFI variables are not supported on this system”, but it still seems to have installed OK (as ls /boot/efi/EFI returns “grub” in addition to “APPLE”).
Next, I generated grub.cfg:
grub-mkconfig -o /boot/grub/grub.cfg
I’ll note that it seems to have found OS X on the correct partition, although given my experience in Debian I bet the menu item won’t work. We’ll see. Next, I rebooted into OS X – I seem not to have broken anything, although the EFI firmware seems to take slightly longer to get to the Apple logo as opposed to just the grey screen (it might be just me, not sure).
In preparation for using bless I mounted the EFI partition in OS X:
sudo mkdir /mnt sudo mount -t msdos /dev/disk0s1 /mnt cd /mnt
Next I did this exact sequence of commands, rebooting in between each one to check if it worked (and remounting every time I rebooted):
sudo bless --folder /mnt/ --bootefi EFI/grub/grubx64.efi
This yielded different, and arguably better results than my attempt from Debian did. What happened this time was that “EFI Boot” is now offered as an option when you hold Option, along with “Macintosh HD” and “Recovery-$YOUR_INSTALLED_OS_X_VERSION”.
GRUB successfully loaded Arch, but I got dropped to an initrd shell. This was because I had misconfigured it so that the LUKS devices never got created, though, not due to a Mac-specific issue.
This is as far as I’ve gotten, but I’ll be back with more edits later.
Method 2
I have installed Ubuntu 12.04 64bit for Mac on a 2010 MBP. It works for me. No problems installing, etc. But … it appears – and I stress that these are impressions only and not backed up with tests … that power management isn’t quite right, the overall user experience is not as slick as for OS X. Which is strange as I have no problem with Ubuntu 12.04 on a HP notebook.
Like yourself, I’ve tried to get answers but not finding much. Considering that Linus Torvalds uses a MacBook Air, these niggling issues “should” have been fixed. Then again, it might all be due to the fact that I’m using an older MBP.
At the end of the day, I pulled the HD and installed a SSD with OS X on it.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0