View source for Pure Linux iMac Boot

I recently bought a Mac Mini 6,1 (late 2012 model) to replace the giant tower PC 
I was using as a household server. Oddly enough for an Apple product, out of all 
the small-form-factor PCs around with a decent amount of power, it was by far 
the cheapest.
When I installed Ubuntu Saucy (13.10), I was initially faced with an unbootable 
system, which I eventually got to work. When Ubunty Trusty (14.04) came out I 
was hoping things would go better. Sure enough, there was a <code>+mac</code> variant 
installer available (buried behind several download pages), but ths used legacy 
BIOS booting. The non <code>+mac</code> variant simply gave me an unbootable system again.
This wasn’t good enough for me! I used [http://glandium.org/blog/?p=2830 Mike Hommey’s Debian EFI boot instructions], 
and adapted them for recent Ubuntu systems. The result was a Mac Mini that would 
boot Ubuntu Trusty in pure EFI mode, with no rEFInd and no OS X, and with an 
Ubuntu entry in the Mac’s bootloader menu.
Thank you Mike. They were excellent instructions.
Note that I’ve only applied this process to my situation: single-booting Ubuntu 
Trusty (14.04.1) on a Mac Mini 6,1. If you’re knowledgeable enough, you should 
be able to use this to dual/multi-boot, or boot other Linux distros, or use 
other Mac devices. But I haven’t tried any of that myself, so be prepared for 
some surprises.

==Why EFI? Why Not rEFInd?==
Because I can. Because of aesthetics. Because I’m an engineer, and if there’s a 
simpler way to make something work, I’ll try to find it.
If the legacy BIOS boot mode works for you, and you don’t want any fuss, use it! 
If rEFInd works for you, use it! These instructions are for people who just want 
to try it out, or perhaps for installer developers who want a starting point for 
a more general process.
Are there any benefits at all then? Sure:
<ul>
<li>I couldn’t actually figure out how to install rEFInd without keeping OS X 
installed, which meant giving over about 100GB of my 500GB drive to it. No 
thanks.</li>
<li>The Mac bootloader firmware seems to boot about 30s faster.</li>
<li>You have access to various EFI-related utilities.</li><li>You can make yourself a pretty Ubuntu entry in the bootloader menu!</li>
</ul>
<!--more-->
==Equipment==

* A Mac that uses EFI to boot. It is helpful, but not essential, to have OS X still installed.
* Two USB sticks, with at least 2GB capacity. One is for the OS X recovery disk, the other is for the Ubuntu installer.
* The Ubuntu 14.04 installer ISO image (both desktop and server installers should work, but I only tried the server installer). <strong>Do not use the <code>+mac</code> variant.</strong>
* Another machine, preferably also Ubuntu, from which you can 
** make the installer USB drive,
** SSH into the new system, and
** ask for help if things go wrong.
* A monitor, keyboard and mouse (ie. don’t try for a headless install).</li><li>An internet connection for the new machine (preferably ethernet, not WiFi).

==Disclaimer. Warning. Caution. Caveat.==

{{warning|This process will wipe OS X and any other data you have on the machine. All of it! That’s the whole point. Make backups.}}

I’m pretty sure this won’t brick a machine (ie. break it irrepairably). But only pretty sure. If all else fails, you should always be able to reinstall OS X from a recovery disk. But there might be subtle differences between machines that make it harder for you to back out if something goes wrong. Therefore, I really don’t recommend trying this unless you’re reasonably proficient with this sort of thing in general. So as a parallel to the equipment list above, here’s a checklist of concepts that shouldn’t phase you:
<ul>
<li>You should absolutely be comfortable working from a command line.</li><li>You should not be afraid to work from a GRUB command line.</li><li>You should understand how to identify disks on a live/installer system (ie. 
be able to answer the question “is the internal hard drive <code>/dev/sda</code> or <code>/dev/sdb</code>?”)</li>
<li>You should understand disk partitioning (not the low level details, just that the general idea is).</li><li>You should understand that when I use device names or numbers, such as <code>/dev/sda1</code> or <code>UUID=whatever</code>, these may be different for your system.</li>
</ul>

Finally, even though this process only takes a couple of hours, it took me 
<em>weeks</em> to figure it out. This means that if your system is different, you might 
require a lot more time too. So you should be doing this on a machine that you 
can afford to have out of action for a couple of days.

==Preliminary Work in OS X==

{{hint|If you still have OS X installed, this is a good time to create a [http://support.apple.com/kb/HT4848 recovery disk]. And also make those backups 
I told you to make.}}

===That Stupid Startup Noise===

There is only one part of this process that requires starting from scratch if you forget it, and it’s this: turning off that stupid noise that the Mac makes 
upon booting. Despite what you may read, on some systems it is impossible to adjust without OS X installed. Impossible. No, <code>nvram</code> utilities won’t work. No, <code>efibootmgr</code> won’t work. No, the OS X recovery disk won’t help. There is some extra, magical, inaccessible bit of state somewhere that keeps the stupid thing alive that <em>you can only control via a full install of OS X</em>. So if you still have OS X installed, or you don’t mind reinstalling it just for this, do this:
<ul><li>Open the <strong>System Settings</strong>.</li><li>Click on <strong>Sound</strong>.</li><li>Click on <strong>Output</strong>.</li><li>Select <strong>Internal Speakers</strong> (“Type: Built-in”).</li><li>Drag the slider all the way to the left.</li></ul><figure><a href="/trinkets/MacOSXVolume.png"><img alt="OS X Internal Speaker Volume" src="/trinkets/MacOSXVolume.png" width="670" height="489"></a></figure>
If you’re a real optimist, you could open a terminal, run <code>nvram -p</code> and note 
the value for <code>SystemAudioVolume</code>. Mine was this:
<pre>
SystemAudioVolume       %80 
</pre>

==How To Boot From USB==

This isn’t really a step, but it’s complicated enough to warrant its own section. You may need to refer to this a few times. The trick to booting from USB on Macs is to hold down the <code>option</code> key while you press the power button to turn it on. Don’t have an <code>option</code> key? Use <code>alt</code> 
instead. <strong>Note:</strong> I found that on some keyboards (eg. my non-bluetooth wireless keyboard), I needed to repeatedly tap the key until I saw the boot menu. Sometimes it was hit-and-miss, but it never took more than three power cycles to get it.

Doing this should bring up the boot menu. Note that when I say “boot menu,” I don’t mean the GRUB/syslinux boot menu. I mean the Mac’s internal bootloader: it has a grey background, a drop-down menu at the bottom for configuring your internet connection, and a horizontal list of OS logos and descriptions.

[[File:MacBootloader.jpg|center|800|I forgot to take a picture, so this is actually from a completely different machine than mine (hence the blurring of the hard drive label). But your Mac bootloader should look pretty much the same.]]

If your USB drive is bootable, you’ll see one or two orange icons with the USB logo on them. For the Ubuntu installer they will probably be labelled “Windows” (just because) and “EFI boot”. You can use <code>→</code>/<code>←</code> and <code>enter</code> to select the thing to boot, or just click with the mouse.

==Starting the Installer==
Create the installer USB drive using <strong>Startup Disk Creator</strong>. You shouldn’t need extra (persistent) space on it. I used the server edition installer because I use my machine as a server. You might want to use the desktop installer. These instructions should work for either. Please leave a comment below if there are any discrepancies. 

Insert the installer USB drive, and power on the machine while holding <code>option</code>/<code>alt</code>, as per the <a href="#boot-from-usb">boot from USB instructions</a>. The grey screen of the bootloader might stay there for a while (perhaps 30s to a 
minute) before it loads the available boot options. You should see the following options:

* Macintosh HD (unless you’ve already wiped OS X)
* Windows
*EFI boot

Use the arrow keys to select <strong>EFI boot</strong> and press <code>enter</code>.

==Installing Ubuntu==
For the server installer, you will be presented with a GRUB bootloader menu:

[[File:Server-grub.png|center]]

The desktop installer might not show you this; you might instead see a prettier menu with the option to '''Try Ubuntu''' or '''Install Ubuntu'''. In either case, select the '''Install''' option.

You can breeze through the first few steps of the installer, the ones that just configure the installer environment and basic setup. However, you should '''stop when you get to partitioning.'''

Specifically, the steps you can treat as normal are:
*Language/region/keyboard layout.
*Hardware detection, disk detection, loading installer components.
*Network detection and configuration.
*Hostname and user account setup.
*Home directory encryption (in case it wasn’t clear, you can enable this if you like, it won’t affect anything here).</li><li>Time, date and time zone.

Around this point, you should be expecting to see the partitioning menu. This is 
where it can get a bit tricky.

==Partitioning==

As far as I can tell, you should actually be able to let this step go as per the defaults too. But I’ll tell you exactly what I did, just in case the defaults don’t allow you to follow the remaining steps.

I got to a screen titled '''Partition disks''', which presented me with these 
options:
*Guided - use entire disk
*Guided - use entire disk and set up LVM
*Guided - use entire disk and set up encrypted LVM
*Manual

I selected '''Guided - use entire disk'''. When asked which disk I wanted to partition, I selected the only one available:
<pre>
SCSI (0,0,0) (sda) - 500.1 GB ATA APPLE HDD HTS545 
</pre>

Yours might be different, but it should be obvious which it is. Incidentally, this might be a good point to note down whether the installer sees your disk as <code>sda</code> or some other <code>sdX</code>. When you proceed, you’ll be shown the changes that will be made:
<pre>
The partition tables of the following devices are changed: 
SCSI (0,0,0) (sda) 

The following partitions are going to be formatted: 
partition #1 of SCSI (0,0,0) (sda) as EFIboot 
partition #2 of SCSI (0,0,0) (sda) as ext4 
partition #3 of SCSI (0,0,0) (sda) as swap 
</pre>

'''This is the important thing:''' at the end of this step, there must be a partition that is listed as <code>EFIboot</code>. As long as that exists, you should be fine to continue. The others probably don’t matter. If you see any partition labelled anything like '''BIOS legacy boot''' or '''bios-grub''', you might have missed a vital part of these instructions and are using the <code>+mac</code> variant of the installer.

Because I was doing this over and over again, I occasionally encountered a problem where the installer would be unable to format the EFIboot partition. If 
this happens, try <a href="#zero-the-drive">zeroing the drive</a> and start over. You may now proceed with the rest of the installation as usual. If you’re 
installing a server, I strongly recommend installing the '''OpenSSH server''' task so that you can do the next few steps remotely.
Congratulations! You now have an unbootable Ubuntu system! Hooray!

==The Manual Boot==

Your new system is unbootable, but don’t despair! We’ll repair it and make it better than it would have been!
Firstly, when you reboot/power on your Mac, here’s what will probably happen: you will see the grey screen of the Mac bootloader for about 30s, and then a 
gently flashing folder with a <code>?</code> inside. If you insert the installer USB now, it should boot. If not, try holding the power button to force the power off, and then follow the <a href="#boot-from-usb">USB booting instructions</a> to bring it up. If you’re using the desktop installer, hold the shift key to bring up the GRUB bootloader menu. For the server installer, it should just come up automatically. 

To be absolutely clear, for <strong>both</strong> the server and the desktop installer, you want to bring up a menu that looks like this:

[[File:Server-grub.png"|center]]

The entries may be different, but that’s what the GRUB menu looks like. Don’t select any of the entries; instead, press <code>C</code> to bring up the GRUB console. Now you should be looking at a GRUB console:
<pre>
grub> 
</pre>

===Finding Your Installation’s Drive===

At the GRUB console, do:
<pre>
grub> ls 
(memdisk) (hd0) (hd0,msdos) (hd1) (hd2) (hd2,gpt3) (hd2,gpt2) (hd2,gpt1) 
</pre>

You may not get exactly the same results as this, but you’ll have some similar options. You want to look for your new installation, <strong>not</strong> the installer/live system. I suggest finding a partition with your new user’s home directory on it:
<pre>
grub> ls (hd2,gpt2)/home
jason/ 
</pre>

Keep trying this pattern until you find it.

===Finding Your Installation’s Boot Partition===

The result from the last step has two parts: <code>(hdX,gptY)</code>. You need to keep the 
<code>hdX</code> part, but go through all the <code>gptY</code> options looking for a <code>/boot/grub</code> 
directory:
<pre>
grub> ls (hd2,gpt1)/boot/grub 
error: file `/boot/grub' not found.</code>
</pre>

Nope, not that one.
<pre>
grub> ls (hd2,gpt2)/boot/grub 
unicode.pf2 [...] grub.cfg 
</pre>

Found it!
Now you want to set this as your root for further commands:
<pre>
grub> set root=(hd2,gpt2)
</pre>

===Figuring Out the Boot Command===

I found that the <em>only</em> way to boot properly was to use the UUID of the drive (ie. no shortcuts with <code>/dev/sdaX</code>!) - so let’s get that:
<pre>
grub> ls -l (hd2,gpt2) 
Partition hd2,gpt2: Filesystem type ext* 〈...snip...〉 UUID e86c20b9-83e1-447d-a3be-d1ddaad6c4c6 - Partition start at [...] 
</pre>

<strong>Note the UUID string!</strong> Yours will be different. Now tell GRUB where Linux is:
<pre>
grub> linux /boot/vmlinuz〈...tab here!...〉.efi.signed root=UUID=〈the UUID from above〉
</pre>

The GRUB console can do <code>tab</code> completion, so if you just type out the <code>vmlinuz</code> part and hit <code>tab</code>, then hit <code>.</code> and <code>tab</code> again… you won’t have to type out the whole filename. But do make sure the <code>.efi.signed</code> bit is there! And yes, you will have to type out that whole UUID.

Now set the <code>initrd</code> (initial RAM disk):
<pre>
grub> initrd /boot/initrd〈...tab here!...〉 
</pre>

===Booting===
Type:
<pre>
grub> boot 
</pre>

You should find yourself booted into your installation!

==Fixing the EFI Partition==
So why is the system unbootable? The problem is that the Mac bootloader expects 
the EFI partition to be formatted as HFS+, the typical Mac filesystem. It also 
expects certain files to be present. The Ubuntu installer actually formats it as 
VFAT and doesn’t create the files that are necessary for booting on a Mac.

===Install Extra Packages===

The first thing you’ll need to do is add my PPA and install some extra utilities. Fire up a command line and enter:

<pre>
$ sudo add-apt-repository ppa:detly/mactel-utils 
[...] 
Utilities for Intel based Macs (eg. recent MacBooks, Mac Minis). Includes a 
fan control (macfanctld) and the HFS "bless" utility. 
More info: 
https://launchpad.net/~detly/+archive/ubuntu/mactel-utils
Press [ENTER] to continue or ctrl-c to cancel adding it 
</pre><ref>[https://launchpad.net/~detly/+archive/ubuntu/mactel-utils Reference]</ref>

Press <code>enter</code> to add the PPA. Then update your package list and install the 
necessary utilities:

<pre>
$ sudo apt-get update 
$ sudo apt-get install mactel-boot hfsprogs gdisk grub-efi-amd64 
</pre>

===Reformatting the EFI Partition===
Firstly, make sure you’ve actually got an EFI partition. Run <code>mount</code> to get a list of mounted filesystems, and look for anything mounted at <code>/boot/efi</code>:
<pre>
$ mount 
[...] 
/dev/sda1 on /boot/efi type vfat (rw) 
[...] 
</pre>

For me, it’s <code>/dev/sda1</code>. If there is no entry for <code>/boot/efi</code> (<code>/boot</code> by 
itself doesn’t count), you are probably running in legacy BIOS mode. So, let’s unmount it:

<pre>
$ sudo umount /dev/sda1 
</pre>

We now use <code>gdisk</code> to delete the VFAT partition and create an HFS+ one. <code>gdisk</code> 
is interactive, and doesn’t write changes to the disk until you tell it to, so 
don’t panic if you make a mistake.

<pre>
$ sudo gdisk /dev/sda 
GPT fdisk (gdisk) version 0.8.8 

Partition table scan: 
MBR: hybrid 
BSD: not present 
APM: not present 
GPT: present 

Found valid GPT with hybrid MBR; using GPT. 

Command (? for help): 
</pre>

You <strong>must</strong> see the <code>GPT: present</code> line. The <code>MBR: hybrid</code> line is optional. If you’re not using a <code>GPT</code> (GUID partition table)… well, I don’t know what kind of machine you’re using there. Print the partition table and confirm that the first partition has type <code>EF00</code>:

<pre>
Command (? for help): p 
Disk /dev/sda: 976773168 sectors, 465.8 GiB 
Logical sector size: 512 bytes 
Disk identifier (GUID): 717BD65E-A514-4FD9-A4A7-1BE01C2F31E0 
Partition table holds up to 128 entries 
First usable sector is 34, last usable sector is 976773134 
Partitions will be aligned on 2048-sector boundaries 
Total free space is 4077 sectors (2.0 MiB) 

Number  Start (sector)    End (sector)  Size       Code  Name 
1            2048          194559   94.0 MiB    EF00 
2          194560       968574975   461.8 GiB   8300 
3       968574976       976771071   3.9 GiB     8200 
</pre>

The other details aren’t really important, but we definitely expect the device 
associated with <code>/boot/efi</code> (from the output of <code>mount</code>) to match the numbering 
here (ie. if <code>/boot/efi</code> was <code>/dev/sda1</code>, the <code>EF00</code> partition should be #1).
Now we delete that <code>EF00</code> partition:
<pre>
Command (? for help): d 
Partition number (1-3): 1 
</pre>

…and create a new HFS+ one in its place:

<pre>
Command (? for help): n 
Partition number (1-128, default 1): 1 
</pre>

Just press <code>enter</code> for the first and last sector options:

<pre>
First sector (34-976773134, default = 2048) or {+-}size{KMGTP}: 
Last sector (2048-194559, default = 194559) or {+-}size{KMGTP}: 
</pre>

…but enter <code>AF00</code> for the filesystem code:

<pre>
Current type is 'Linux filesystem' 
Hex code or GUID (L to show codes, Enter = 8300): AF00 
Changed type of partition to 'Apple HFS/HFS+' 
</pre>

Now we’re ready to write the changes. Use the <code>p</code> command to double-check your 
changes, and then <code>w</code> to write:

<pre>
Command (? for help): w 

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING 
PARTITIONS!! 

Do you want to proceed? (Y/N): Y 
OK; writing new GUID partition table (GPT) to /dev/sda. 
Warning: The kernel is still using the old partition table. 
The new table will be used at the next reboot. 
The operation has completed successfully. 
</pre>

Now we have an unformatted HFS+ partition. We can format it with:
<pre>
$ sudo mkfs.hfsplus /dev/sda1 -v Ubuntu 
Initialized /dev/sda1 as a 94 MB HFS Plus volume 
</pre>

===Updating the Filesystem Table===

For system partitions (eg. <code>/</code>, <code>/boot</code>, <code>/boot/efi</code>) Ubuntu uses the UUID 
(universally unique identifier) of a disk partition to mount it (rather than 
the device node, eg. <code>/dev/sda1</code>). This means we need to update <code>/etc/fstab</code>:<pre>$ sudoedit /etc/fstab 
</pre>
This will launch the <code>nano</code> text editor. Look the two lines that 
refers to <code>/boot/efi</code>:<pre># /boot/efi was on /dev/sda1 during installation 
UUID=C59D-1B30  /boot/efi       vfat    defaults        0       1 
</pre>
Use <code>↓</code>/<code>↑</code> to position the cursor at the start of these lines and hit 
<code>ctrl</code>+<code>K</code> to delete them. Run this to add the necessary entries:<pre>$ sudo bash -c 'echo $(blkid -o export -s UUID /dev/sda1) /boot/efi auto defaults 0 0 >> /etc/fstab' 
</pre>
Test it out by remounting <code>/boot/efi</code>:<pre>$ sudo mount /boot/efi 
</pre>
Note that you shouldn’t use extra options here. If it doesn’t work from that 
command alone, it means your <code>/etc/fstab</code> entry is wrong.

===Installing GRUB===

Now we’ll reinstall GRUB so it can use the newly formatted HFS+ partition for 
its EFI data. Since Mike Hommey wrote his instructions, GRUB has actually been 
updated to work with HFS+ partitions, so there’s no need to hack the installer 
any more (good thing too, since it’s now a C program, not a shell script).
First, create the necessary directory on the EFI partition:

<pre>
$ sudo mkdir -p "/boot/efi/EFI/$(lsb_release -ds)/" 
</pre>

The <code>$(lsb_release -ds)</code> part automatically produces a label for the 
distribution like <code>Ubuntu 14.04.1 LTS</code>.
Now, there’s a <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716927#20">bug in GRUB</a> 
that means that on HFS+ it requires a file named <code>mach_kernel</code> to exist in a 
particular place before it runs. In fact, it’s really the Mac bootloader that 
requires this file, but GRUB seems to look for it in the wrong place and refuses 
to run if it’s not there, so we need to create it twice:

<pre>
$ sudo bash -c 'echo "This file is required for booting" > "/boot/efi/EFI/$(lsb_release -ds)/mach_kernel"' 
$ sudo bash -c 'echo "This file is required for booting" > /boot/efi/mach_kernel' 
</pre>

Now we need to install GRUB, and we need to be a bit explicit about where it 
should put its files:

<pre>
$ sudo grub-install --target x86_64-efi --boot-directory=/boot --efi-directory=/boot/efi --bootloader-id="$(lsb_release -ds)" 
</pre>

The final step is to “bless” the bootloader code, so that the Mac bootloader 
will boot it:

<pre>
$ sudo hfs-bless "/boot/efi/EFI/$(lsb_release -ds)/System/Library/CoreServices/boot.efi" 
</pre>

<strong>The system should now be bootable!</strong>

You should reboot your system (<code>sudo reboot</code>) to see if it boots straight into your new Ubuntu installation. '''Note''' that there will still be that delay at the Mac boot screen (the light grey one). But the system will still boot, and we can get rid of that delay later. You might also like to <a href="#boot-from-usb">bring up the boot menu</a> to see what the Ubuntu entry looks like. At this point it should have the correct label (“Ubuntu 
14.04.1 LTS…”), but the icon will be a plain grey hard drive.

===Replacing the Bootloader Icon===

Simply do:

<pre>
$ sudo apt-get install mactel-boot-logo 
$ sudo cp /usr/share/mactel-boot-logo/ubuntu.icns /boot/efi/.VolumeIcon.icns 
</pre>

Now when you reboot, if you bring up the Mac boot menu, you should see the familiar Ubuntu logo!<figure><a href="/trinkets/MacBootloaderUbuntu.jpg"><img src="/trinkets/MacBootloaderUbuntu.jpg" width="400" height="438"></a></figure>

==Removing the Boot Delay==

The boot delay is caused by a couple of things:

* The bootloader firmware might still have old entries in it, with the default set to something that doesn’t exist.</li><li>The bootloader itself has a timeout that can be changed, and it defaults to 5s.

This can be managed with the <code>efibootmgr</code> utility. If you run it without arguments, you’ll see all the settings I mentioned:

<pre>
$ sudo efibootmgr 
BootCurrent: 0000 
Timeout: 5 seconds 
BootOrder: 0080 
Boot0000* ubuntu 
Boot0001* Ubuntu 14.04.1 LTS 
Boot0080* Mac OS X 
BootFFFF* 
</pre>

In my case, the timeout was set to 5s, the default boot was set to an entry that no longer exists, and there was still an old OS X entry. This will get rid of the built-in timeout:

<pre>
$ sudo efibootmgr -t 0 
</pre>

This gets rid of the extra entries (<em>note that your numbers might be different!</em>):

<pre>
$ sudo efibootmgr -b 0000 -B 
$ sudo efibootmgr -b 0080 -B 
</pre>

This sets the default entry (<em>again, the number here might be different for you</em>):

<pre>
$ sudo efibootmgr -o 0001 
</pre>

…and now, when you reboot, it should be significantly faster.

{{note|When I initially searched for a fix for this, I read a lot of posts claiming that using the OS X recovery disk to bless the partition would do the trick. But as far as I can tell, this has no effect, so don’t panic if you don’t have a recovery disk.|subject=Note #1}}

{{note|I am not talking about the usual GRUB delay here. In theory, this can be changed by editing <code>/etc/default/grub</code> and setting all the timeout values to <code>0</code>. However, [https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1273764 bug #1273764] stops this from working, so use [https://gist.github.com/LeahCim/9332432 LeahCim’s extra GRUB scripts] to fix it.|subject=Note #2}}

==You’re Done!==

That should be it. You should now have a system that boots straight into Ubuntu, 
no delay, giving you access to all the EFI goodness.

==Zeroing the Hard Drive==

<strong>This is not a step!</strong> It’s just here in case things go so wrong you don’t know what to do. Hopefully you won’t need this bit, but you may find that the installer partitioner isn’t working as expected, or maybe you’ve tried a load of different things and you want a clean slate. You could reinstall OS X, but that takes time and data. In most cases, I found that zeroing out the start of the drive was enough to get rid of any bad state 
that was interfering with the process.

Boot off the Ubuntu installer USB drive, but don’t select <strong>Install Ubuntu</strong>. Instead, use the <strong>Rescue a broken system</strong> option.
Go through the keyboard detection, but don’t bother with anything else — as soon as you see a <code><go back></code> option, use that to get to the rescue menu. Select <strong>Execute a shell in the installer environment</strong>, and you’ll be presented with a prompt that’s just a <code>#</code> (ie. root access). Assuming your hard drive is <code>/dev/sda</code>, this command will zero out the first GB of the hard drive. That should cover the master boot record (MBR), the GUID partition table (GPT), and any other magic that interferes with partition/OS detection:

<pre>
# dd if=/dev/zero of=/dev/sda bs=16M count=64 
</pre>

It will <strong>not</strong> touch the Mac’s internal bootloader firmware, nor will it reset any nvram variables such as the internal speaker volume.

[[Category:Linux]][[Category:iMac]][[Category:EFI Boot]]{{keywords|linux,iMac,boot,partitioning,EFI boot}}{{description}}{{ogmeta}}