Recently I had the 250 gig hard drive in my Macbook Pro replaced by Apple (under warranty). I had two volumes on it; one large ("Macbook") with all my work, etc. on it, and one small ("Rescue") containing a bare bones OS plus Drive Genius, for repairs and such without needing the CD. I'd done a complete backup before the hard drive replacement, then used Super Duper to restore "Macbook" back to the new drive, which I'd partitioned using the OS X install disk.
Everything seems to work fine except that when I hold down the option key to switch between boot volumes, my choices are now "EFI Boot" (instead of "Macbook") and "Rescue", even though in the finder, "Macbook" shows up normally.
What's happening, and what can I do about it? I've never seen this before. Thanks.
Hi, this just happened to me too. I don't know if the problem results from cloning the drive, but that's when I noticed it. I pulled my internal drive from my Macbook, installed it in a USB case, and then cloned it to a new drive I had installed in the Macbook, and both disks show up in the startup disk chooser as "EFI Boot" rather than with their correct name. The correct name appears in Disk Utility.
Don't know of any solution, can someone help? Or at least let us know if this is something that will cause trouble down the road?
The gory details:
Booted up from an old backup on an external firewire drive. Used Carbon Copy Cloner to clone my up-to-date main drive, which was pulled from my Macbook and installed in an external usb case, onto a new, larger internal drive I had just installed in my Macbook.
On restart, the Macbook wouldn't boot at all with the new cloned drive installed (yes, it was formatted as mac os extended journaled w/GUID partition), but gave some error messages at a command line and stalled (including "syslogd: exited abnormally: Bad system call," "config file /etc/notify.conf not owned by root:ignored," "com.apple.nibindd: exited abnormally: Bad system call," and finally "my-computer:/ I have no name!#"). Removing the internal drive allowed me to use the 'option' key to select the FW drive as startup disk & boot from it.
Disk utility wouldn't allow me to repair permissions on either the source of the clone in the USB case, or the target, once I removed it from the Macbook and installed into the USB case in turn. In both cases, DU showed "Owners enabled: no." Using a command I found online & entered into the terminal (vsdbutil -a), I was able to reset it to "Owners enabled: yes" and repair permissions on both drives. I could then boot from either of them installed in the USB case. (Probably unrelated, but it seems the clone operation didn't work %100: on the target drive, I got some messages saying some .kext files were not installed properly, even though the source doesn't seem to have any problems; so will try the clone again).
However, now when starting up with option held down, both of these drives that I was copying to/from show up as "EFI Boot" rather than their correct names. (The old FW backup that wasn't part of the clone is fine). When installed in my Macbook, the "EFI Boot" drive will boot properly, except that there is the folder-with-question-mark that flashes up for half a second before the apple icon appears and booting up begins.
EFI Boot is suppose to be an invisible hard drive that is full of well, nobody knows. You don't really have much use for it, but this boot disk appears when you're messing with your drive. (Doesn't appear all the time though.
Just to be clear: on my machine, "EFI Boot" doesn't appear as an additional drive, but appears in the startup chooser as the name of my main drive that has OS X installed on it.
Realized I did something else to my new drive before cloning to it that could have had a role in making this happen: I ran TechTool Deluxe HD diagnostic & surface scan on my new drive (after it had been formatted to Mac OS extended/journaled). I wonder if TTD turns "owners enabled" to "no" (that is, the equivalent of doing get info on a drive and checking "ignore ownership on this volume"). Or perhaps the drive was just formatted this way to begin with? Anyway, I didn't catch the "ignore ownership" thing until after I had cloned my drive, and so perhaps turning ownership back on after OS X is installed has something to do with the name change in the startup chooser??? Or could it be something else TTD does to the drive?
The structure and organization and function of EFI is reasonably well understood; some of us have been working with EFI for a number of years now on other platforms.
There are areas that won't be obvious and won't be easy (details of Apple's ACPI tables will probably be murky), but EFI itself isn't that difficult.
It'd be interesting to use rEFIt or other tools to look at the GPT and specifically at the GUIDs and related. Here, I'd expect there's some sort of a duplicate error. I might well look to boot to the EFI shell and remove and re-add the boot aliases here, or re-name the existing aliases.
If you have two block-cloned disks (and thus with the same GUID signatures), EFI really doesn't like that. EFI expects the GUIDs to be unique, and those GUID values are central to how EFI finds the target disk and target partitions.
I have realized that the partition map on my disks may have been different. After erasing the bad clone on the target drive, and getting ready to install again, the drive showed up as Apple Partition Map. This suggests that it was Apple Partition Map the first time around too (and so I was mistaken in my above post: I had confirmed only the source drive was GUID, not the target drive.)
I had assumed Tiger's Disk Utility defaulted to GUID when erasing a new disk that shipped as NTFS or FAT (and I also missed the possibility to specify the partition map because those options are in the 'partition' tab of DU rather than 'erase'). Turns out it's likely the new target drive I erased with DU had been given the older Apple Partition Map scheme; I had then cloned to it from my GUID source drive with OS X. I think this is why the new target drive would show up as "EFI Boot" on an intel mac? (And also why the clone didn't fully succeed, with some kexts not properly installed?) Don't know why DU defaulted to APM when erasing the new drive...
It also turns out that my GUID source drive had been earlier (after a crash & drive replacement) cloned from an older, PPC-era firewire backup drive that had been also been formatted as Apple Partition Map. So I'm guessing that cloning from APM to GUID also caused the GUID drive to show up as "EFI Boot" as well? It seems going APM --> GUID earlier didn't produce any problems other than the appearance of "EFI Boot" in the startup chooser, and a slight delay on bootup; then going GUID --> APM again produced, in addition to "EFI Boot," problems in the clone of my new target drive...?
In the end, I used the occasion to install Leopard (erase & install + migration assistant) and in the process have reformatted both my new internal drive and the backup drive as GUID. Solved my problem, but I'm afraid doesn't provide any continuing diagnosis of the problem for others.
Moral of the story: double check your partition map on cloned source & target drives.
(Disk Utility > click on top level drive, not mounted volume > partition info at bottom right. To change partition map, erase existing disk & partitions (backup first!): Partition > Volume Scheme > choose number of partitions, then click Options, then Apply.)
For what it's worth, and I could not say what I did (if anything) to effect this - but now holding down the "option" key brings up both volumes on the hard drive, with their correct names. I did run Drive Genius a couple of times, seemingly without effect. I use SuperDuper to clone backups to a USB pocket hard drive, without anything unexpected happening. It is a puzzlement.
