Actions

Difference between revisions of "Pure Linux iMac Boot"

From InfoTechPedia

(Zeroing the Hard Drive)
Line 505: Line 505:
 
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.
 
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}}
+
[[Category:Linux]][[Category:iMac]][[Category:EFI Boot]]{{keywords|linux,iMac,boot,partitioning,EFI boot}}{{description}}[{ogmeta}}

Revision as of 11:02, 3 November 2020

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 +mac variant installer available (buried behind several download pages), but ths used legacy BIOS booting. The non +mac variant simply gave me an unbootable system again. This wasn’t good enough for me! I used 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:

  • 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.
  • The Mac bootloader firmware seems to boot about 30s faster.
  • You have access to various EFI-related utilities.
  • You can make yourself a pretty Ubuntu entry in the bootloader menu!

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). Do not use the +mac variant.
  • 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).
  • 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:

  • You should absolutely be comfortable working from a command line.
  • You should not be afraid to work from a GRUB command line.
  • You should understand how to identify disks on a live/installer system (ie. be able to answer the question “is the internal hard drive /dev/sda or /dev/sdb?”)
  • You should understand disk partitioning (not the low level details, just that the general idea is).
  • You should understand that when I use device names or numbers, such as /dev/sda1 or UUID=whatever, these may be different for your system.

Finally, even though this process only takes a couple of hours, it took me weeks 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 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, nvram utilities won’t work. No, efibootmgr 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 you can only control via a full install of OS X. So if you still have OS X installed, or you don’t mind reinstalling it just for this, do this:

  • Open the System Settings.
  • Click on Sound.
  • Click on Output.
  • Select Internal Speakers (“Type: Built-in”).
  • Drag the slider all the way to the left.

<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 nvram -p and note the value for SystemAudioVolume. Mine was this:

SystemAudioVolume       %80 

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 option key while you press the power button to turn it on. Don’t have an option key? Use alt instead. Note: 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.

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 / and enter to select the thing to boot, or just click with the mouse.

Starting the Installer

Create the installer USB drive using Startup Disk Creator. 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 option/alt, 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 EFI boot and press enter.

Installing Ubuntu

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

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).
  • 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:

SCSI (0,0,0) (sda) - 500.1 GB ATA APPLE HDD HTS545 

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 sda or some other sdX. When you proceed, you’ll be shown the changes that will be made:

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 

This is the important thing: at the end of this step, there must be a partition that is listed as EFIboot. 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 +mac 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 ? 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 both the server and the desktop installer, you want to bring up a menu that looks like this:

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

grub> 

Finding Your Installation’s Drive

At the GRUB console, do:

grub> ls 
(memdisk) (hd0) (hd0,msdos) (hd1) (hd2) (hd2,gpt3) (hd2,gpt2) (hd2,gpt1) 

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, not the installer/live system. I suggest finding a partition with your new user’s home directory on it:

grub> ls (hd2,gpt2)/home
jason/ 

Keep trying this pattern until you find it.

Finding Your Installation’s Boot Partition

The result from the last step has two parts: (hdX,gptY). You need to keep the hdX part, but go through all the gptY options looking for a /boot/grub directory:

grub> ls (hd2,gpt1)/boot/grub 
error: file `/boot/grub' not found.</code>

Nope, not that one.

grub> ls (hd2,gpt2)/boot/grub 
unicode.pf2 [...] grub.cfg 

Found it! Now you want to set this as your root for further commands:

grub> set root=(hd2,gpt2)

Figuring Out the Boot Command

I found that the only way to boot properly was to use the UUID of the drive (ie. no shortcuts with /dev/sdaX!) - so let’s get that:

grub> ls -l (hd2,gpt2) 
Partition hd2,gpt2: Filesystem type ext* 〈...snip...〉 UUID e86c20b9-83e1-447d-a3be-d1ddaad6c4c6 - Partition start at [...] 

Note the UUID string! Yours will be different. Now tell GRUB where Linux is:

grub> linux /boot/vmlinuz〈...tab here!...〉.efi.signed root=UUID=〈the UUID from above〉

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

Now set the initrd (initial RAM disk):

grub> initrd /boot/initrd〈...tab here!...〉 

Booting

Type:

grub> boot 

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:

$ 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 

[1]

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

$ sudo apt-get update 
$ sudo apt-get install mactel-boot hfsprogs gdisk grub-efi-amd64 

Reformatting the EFI Partition

Firstly, make sure you’ve actually got an EFI partition. Run mount to get a list of mounted filesystems, and look for anything mounted at /boot/efi:

$ mount 
[...] 
/dev/sda1 on /boot/efi type vfat (rw) 
[...] 

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

$ sudo umount /dev/sda1 

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

$ 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): 

You must see the GPT: present line. The MBR: hybrid line is optional. If you’re not using a GPT (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 EF00:

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 

The other details aren’t really important, but we definitely expect the device associated with /boot/efi (from the output of mount) to match the numbering here (ie. if /boot/efi was /dev/sda1, the EF00 partition should be #1). Now we delete that EF00 partition:

Command (? for help): d 
Partition number (1-3): 1 

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

Command (? for help): n 
Partition number (1-128, default 1): 1 

Just press enter for the first and last sector options:

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

…but enter AF00 for the filesystem code:

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

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

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. 

Now we have an unformatted HFS+ partition. We can format it with:

$ sudo mkfs.hfsplus /dev/sda1 -v Ubuntu 
Initialized /dev/sda1 as a 94 MB HFS Plus volume 

Updating the Filesystem Table

For system partitions (eg. /, /boot, /boot/efi) Ubuntu uses the UUID (universally unique identifier) of a disk partition to mount it (rather than

the device node, eg. /dev/sda1). This means we need to update /etc/fstab:

$ sudoedit /etc/fstab 

This will launch the nano text editor. Look the two lines that

refers to /boot/efi:

# /boot/efi was on /dev/sda1 during installation 
UUID=C59D-1B30  /boot/efi       vfat    defaults        0       1 

Use / to position the cursor at the start of these lines and hit

ctrl+K to delete them. Run this to add the necessary entries:

$ sudo bash -c 'echo $(blkid -o export -s UUID /dev/sda1) /boot/efi auto defaults 0 0 >> /etc/fstab' 

Test it out by remounting /boot/efi:

$ sudo mount /boot/efi 

Note that you shouldn’t use extra options here. If it doesn’t work from that command alone, it means your /etc/fstab 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:

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

The $(lsb_release -ds) part automatically produces a label for the distribution like Ubuntu 14.04.1 LTS. 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 mach_kernel 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:

$ 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' 

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

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

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

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

The system should now be bootable!

You should reboot your system (sudo reboot) 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:

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

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.
  • The bootloader itself has a timeout that can be changed, and it defaults to 5s.

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

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

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:

$ sudo efibootmgr -t 0 

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

$ sudo efibootmgr -b 0000 -B 
$ sudo efibootmgr -b 0080 -B 

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

$ sudo efibootmgr -o 0001 

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

Note #1
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.
Note #2
I am not talking about the usual GRUB delay here. In theory, this can be changed by editing /etc/default/grub and setting all the timeout values to 0. However, bug #1273764 stops this from working, so use LeahCim’s extra GRUB scripts to fix it.

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

This is not a step! 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 Install Ubuntu. Instead, use the Rescue a broken system option. Go through the keyboard detection, but don’t bother with anything else — as soon as you see a <go back> option, use that to get to the rescue menu. Select Execute a shell in the installer environment, and you’ll be presented with a prompt that’s just a # (ie. root access). Assuming your hard drive is /dev/sda, 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:

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

It will not touch the Mac’s internal bootloader firmware, nor will it reset any nvram variables such as the internal speaker volume.[{ogmeta}}