I've been following this Mac/Windows/EFI thing for some time and I'm eager to run Windows on my iMac (many thanks to all those who worked this out!).

There's a few things that bother me, and I think they are more general EFI questions than to do with the Windows installation -

The EFI partition on the hard drive - Is this where EFI lives, or is it just a place that files EFI uses (xom.efi?) are pulled from?

If I was to remove the partition would it destroy my Mac?

If that is the case, then is it the same on 'normal' computers with EFI? and how do you upgrade a hard drive in a computer that has it (does the disk come with EFI already on it)?

Here's my limited understanding: EFI is like a Lego set. EFI is a platform that lives in firmware that lets you program your own modules to load, and is highly customizable because of that.

There is no such thing as an "efi partition", only EFI chipsets on motherboards. Then, the firmware looks for the EFI modules (in the case of the Mac, in /System/Library/CoreServices). The EFI in firmware is programmed to look for modules where the programmers specify. So, the firmware that is made by Apple looks for the EFI module that resides on your Mac partition, and that module is written by Apple to be nearly identical to the way a Mac booted from firmware (also sans BIOS).

But lo! Thanks to Blanka and Narf, we just replace that with a cleverly written replacement EFI module. This solution actually REQUIRES a Mac OS X partition, since that's where the EFI is looking for the boot module. If you wanted to run ONLY windows, with no Mac OS X partition, you'd have to run a pretend BIOS like BAMBIOS, which doesn't exist yet.

Without any partitions on the hard disk, it just loads the EFI modules it has to in order to boot to the Mac OS CD, so you can load the OS, and therefore, the permanent EFI modules. That's why every time you run System Update and move your OS up a point release (10.4.5), you'll have to copy the hacked EFI module back into /System/Library/CoreServices.

Does that make sense?

That's crystal clear, thanks!

But how did the poor souls who were playing with the first mactel-linux builds completely brick their macs then? surely they would still have been able to boot from cd?

And the process of 'blessing' the EFI file? Does that modify the EFI in firmware in any way to tell it where to look for the new boot loader?

That's not quite correct. In fact, the EFI specification states that there must be an EFI system partition on the hard disk, formatted with a FAT32 file system. While most of the EFI firmware resides in a ROM chip, this partition is where operating systems are supposed to put their boot loaders. On a GPT-formatted disk created by Apple's Disk Utitily, you'll find such a partition, but it is empty and unused. That's because Apple has customized its firmware to get the bootloader directly from a HFS+ partition (i.e. the volume where OS X is installed). That mechanism can be hooked (using the bless command), which is what XoM, rEFIt and probably also BAMBIOS use to be loaded on boot.



I don't see a connection between those two (CD booting and OS updates). The EFI firmware will happily boot from any partition that has a valid bootloader, no matter on what kind of disk it's on. Also, you can get around the update problem (if there is one) by putting the custom loader on a different volume. (Still has to be HFS+, though.)



EFI maintains a set of variables in NVRAM. For example, one of them points to the partition that should be booted. You can manipulate that variable store using the built-in menus that are accessible on the iMac, right to the point where the machine won't boot at all. In the later models (MBP, Mini) Apple has prevented access to these menus.



Yes and no. Just blessing a different file will not modify the NVRAM. It just sets a pointer in the volume header of the HFS+ volume. The --setBoot option accesses the NVRAM to set the default boot volume. Even then, you should be able to bring up the boot-time volume chooser with the Option key or boot from CD with the C key.

Gotcha.

So if I am understanding correctly, no amount of creating/deleting/resizing partions on the hdd can 'break' the machine, as I can always boot from CD and let the OS X installer recreate all the needed GPT and EFI stuff, using the C key?

That's what some of the other people that hosed their system (couldn't boot, couldn't format) wanted to know in another thread. The most recent post says that the CD can reinitialize the disk, and you'd be fine.

This thread has been muy educational! Thanks Christoph!

Thanks guys, this has been a fantastic ride so far

I've been reading conflicting information.

Is it safe to remove the efi partition?

The text under ---- below is from some comments on another site. I don't understand how this could have permanently broken the mac if they only modified the efi fat32 partition?

Also my other question is, can the intel mac efi firmware load efi module from fat32. Or does it have to be a file on an hfs+ partition which has the blessed attribute ?

Again, Ive read conflicted information. rEFIt says no. This thread says no. but else where on this forum someone wrote

Using hidden FAT partition:
# hdiutil attach /path/to/rEFIt.dmg (or mount in Finder)
# mkdir /efi
# mount_msdos /dev/disk0s1 /efi
# cp -r /Volumes/rEFIt/* /efi/.
# echo "TextMode" > /efi/startup.nsh
# bless --mount /efi --file /efi/efi/refit/apps/Shell.efi --setBoot --nextonly
# reboot

which suggests you can set up refit on the hidden fat32 efi partition ?

----

**WARNING** The following instructions will render the iMac Core Duo (Intel) TOTALLY USELESS. There is NO KNOWN METHOD OF RESTORING the iMac Core Duo to a previous functioning state. **WARNING**

I AM NOT KIDDING. THE FOLLOWING METHODS WILL PUT THE IMAC IN A STATE OF DISREPAIR BY AN END USER, EVEN WITH ACCESS TO THE INTERNAL HARDWARE.

With that said, here is how I killed the iMac Core Duo:


1. Downloaded EFI sample implementation and unzipped
2. Moved the 'Binary' folder to the hidden EFI partition (sudo mkdir /Volumes/EFI; sudo mount_msdos /dev/disk0s1 /Volumes/EFI)

*NOTE: this partition appeared EMPTY*

3. 'blessed' /Volumes/EFI/BIOS32/Bin/GraphicsConsole.efi
4. Rebooted in to GraphicsConsole
5. Attempted to load an EFI 'Driver' via GraphicsConsole (I forget the process, but it was a submenu. The drivers I attempted were AtapiPassThru.efi and Partition.efi)
6. Reboot and stare at your new broken iMac Core Duo. It's dead, Jim...

Just as Dave mentioned, unplugging the Hard Drive, removing the battery and leaving the iMac without power WILL NOT RESET IT TO ITS FACTORY DEFAULTS.

Because settings are stored in NVRAM, POWER IS NOT REQUIRED TO KEEP THE SETTINGS INTACT.

http://en.wikipedia.org/wiki/Flash_memory

BECAUSE THE APPLE EFI SOFTWARE DOES NOT LOAD THERE IS NO WAY TO 'ZAP' or 'FLASH' THE NVRAM TO DEFAULTS.

It is safe. My iMac's hard disk is formatted in MBR/fdisk format, no EFI system partition whatsoever, and I'm happily triple-booting.



Well, the text you quote suggests that the firmware can load an EFI application from a FAT32 partition after all. I haven't been able to confirm that so far, but I'll try again this evening. It could be that the built-in chooser (which you get when you hold the Option key) only shows HFS+ volumes, but when you use 'bless --setBoot' it still works... Although I don't know how the firmware finds the blessed file on a FAT32 volume, because it uses special fields in the volume header on HFS+.



Well, it would be interesting to know what this guy really did in step 5. I'd like to note that both GraphicsConsole and Partition are already present in the built-in firmware. (I'm not sure about AtapiPassThru. And you may want to read the EFI page in the Wiki.)

Even when 'bless' has set the boot volume to the FAT32 partition and it refuses to boot, it should still be possible to bring up the built-in chooser with Option or boot from CD with 'C'. Not sure what this guy has actually tried to get his iMac back to life... On the other hand, maybe he really managed to disable Apple's custom chooser/loader module by messing with the lower-level "Boot Manager" settings.

To follow up on this -- booting from a FAT volume works, but only in a limited way. The knack is that the example posted by exobuzz uses 'bless --mount', not 'bless --folder'. The '--file' option works differently when used with '--mount' and actually stores the path to the file in the NVRAM variable 'efi-boot-device' (resp. 'efi-boot-next' with '--nextonly'). This way the firmware can locate the loader file even on FAT volumes.

However, a FAT volume still can't be blessed the normal way and won't show up in the built-in volume chooser.

This could be extremely useful to me though. Currently I just got linux up and running. I created a small HFS+ partition for elilo. This is all fine, but If I upgrade elilo at any stage remotely, I must rebless the file from the OSX install cd (until there is a way to bless hfs+ partitions in linux).

And these options are definitely safe? I wonder if perhaps it is these options can mess up the firmware. So long as this boot stuff happens after the firmware stuff for booting off cd, then its no problem I guess.

OK. I got elilo running off the hidden partition. Good. I did not use the option -nexitonly
Is that needed ?

Can you explain in more detail how that option works.

I just use --mount ... --file ...