Jump to content

How does BIOS boot GPT (GUID) Hard Drives?

socal swimmer

4 posts in this topic

Recommended Posts

I will use GUID and GPT interchangeably to mean GPT, even though they are technically not the same:


I installed using brazilmac, onto a GUID formatted hard drive with efi v8. Everything was working great for a week, until silly me, I did the following (from the install dvd):

fdisk -e /dev/rdisk0
Specifies the disc that you have Vista and OS X installed to
The  specified location rdisk0 may of course be different if Vista or OS X  was installed on a different drive, e.g. rdisk1, rdisk2

flag 1
Marks OS X as the active partition 

Update machine code in loaded MBR

Write loaded MBR to disk

This will quit fdisk and take you back to the normal single user prompt

Your machine will restart and boot OS X as normal


I was trying to get a cloned install of vista to boot properly (which was dumb, because I had 32 bit not 64 bit). Anyways, after doing this, Leopard will no longer boot, either by itself, or using the dvd.


I tried to reinstall efi, but when i do this line:

dd if=./guid/boot0 of=/dev/disk1 bs=400  count=1

I get "/dev/disk1: resource busy". Do you know why?


I ran disk utility and repaired the disk. There were errors, which it fixed.


I then try several more times to reinstall efi, but get the same error each time, at that one line of code.


So at this point (after screwing up my hard drive, mostly reinstalling efi, and repairing the drive using disk utility), I try to boot and get "HFS+ Partition Error". I know that there are solutions for this out there, but I think that they are meant to be used on MBR drives, not GUID drives. I am afraid that I will screw it up even more (to the point where no operating system will recognize the data on that drive.



I think that the reason I am having problems is either because I modified the dummy mbr section on the GUID drive, or because I actually wrote over some critical GUID stuff. Because I was able to successfuly repair the drive using disk utility (which can still recognize both partitions), I think that the GUID info is fine. It may have been written over before, but the redundancy of GUID means that Disk Utility was able to restore it. Since the data is fine, and the GUID section is fine, by process of elimination the problem lies in the MBR section (from Wikipedia, this is the first sector, LBA 0). However, Wikipedia said that the MBR is used mainly to protect from disk utilities that don't recognize GUID drives. So how does MBR affect BIOS booting GPT drives? CAn BIOS natively boot GUID drives or does it use some type of emulation present in the MBR section?


So, three main questions:


1) How do I undo what I did, so that I can boot again?


2) How does BIOS boot GUID drives (can it recognize GUID, or does it use the MBR section of the GUID drive)?


3) how do I restore the MBR section of my GUID drive?

Edited by socal swimmer
Link to comment
Share on other sites

I solved it by reinstalling efi.


btw, since I used a different install method (on intel, not amd), your link would have done nothing (or broken it farther).


Anyway I was having trouble installing efi (again) and I solved it by rebooting and unmounting all partitions, then redoing the last line in the efi script (that I got from I_am...me).


All is better (I'm typing from it as I speak).


But thanks for the help!




Ok I swear I'm not crazy. Somone else posted, then deleted .... lol.....

Link to comment
Share on other sites

  • 2 years later...



I really really don't understand why there is so much of stress on GPT/GUID-EFI installation !

I did a MBR installation 10.5.2(oem) and 10.5.6(retail) on both macbook pro 4,1 (2.5Ghz) and PC(E5400,GA-EG45M-UD2H).

It works superbly on both.

Anyways, the EFI partition of my MBP17 had only Firmware.scap( or *.scrap), nothing else.

Leo doesn't use EFI partition for anything.(Yeah TimeCapsule may fail to run, apart from that ? nothing).

I guess GPT/EFI installation is just "hyped" !


On hyped; i would like to draw attention to one more thing....." did a MBR installation 10.5.2(oem) and 10.5.6(retail) on both".....OEM works just fine as Retail on PC !

Again, "OEM works just fine as Retail on PC"


Peace Out !

Link to comment
Share on other sites

To some extent, this is moot for socal swimmer; I'm posting mainly just to inform....


OS X 10.6 retail won't install directly to MBR disks; it will install only to GPT disks. Thus, much of the "hype" around GPT has to do with this fact. There are of course workarounds, but they're awkward or there are problem reports.


Apple's Disk Utility will resize HFS+ partitions on GPT disks, but it won't resize HFS+ partitions on MBR disks. This is another reason for preferring GPT over MBR on any system that runs Mac OS X.


In theory, the BIOS doesn't care about the partitioning system; it should just load the first sector of the hard disk and execute its code. This code is (or should be) the first-stage boot loader, and this code may need to understand the partitioning system, at least well enough to locate a partition and load more boot code (the stage-2 boot loader code). (Sometimes extra "stage 1.5" boot loader code is tucked away in unallocated space immediately after the MBR.) In practice, some BIOSes do try to interpret the MBR partitions, and this can cause problems. For instance, some Intel boards reportedly require that an MBR partition be marked as active before they'll begin the boot process. I own a computer that flakes out and hangs when the EFI protective partition in the MBR is configured to precisely conform to the GPT specification, but it behaves better when this partition is written slightly out of spec, but in a way that's more sensible by the usual MBR conventions. These are BIOS bugs, though; a properly functioning BIOS shouldn't care whether a disk uses MBR, GPT, or any other partitioning system, so long as either it's a data (non-boot) drive or there's boot loader code in the first sector on the disk.


Socal swimmer, I notice that you /dev/rdisk0 in your first code segment but /dev/disk1 in the second one. That's probably the source of the error you reported for the second command; if your system has only one disk, /dev/disk1 doesn't exist, so any attempt to access it will produce an error message.


Although GPT includes backup data, there's no guarantee that it will be accessed and used correctly. I realize you've worked out the problems for now, socal swimmer, but you (and other readers) may want to consider using appropriate tools to verify the state of the disk when running into such problems. Unfortunately, Apple's GUI Disk Utility is useless for this. A combination of Apple's fdisk (for the MBR side) and the text-mode diskutil can provide the data required. So can my own GPT fdisk (gdisk). See my GPT fdisk pages, and particularly the Repairing GPT Disks sub-page, for details on GPT data recovery. Some configurations can produce some nasty conditions, particularly if a hybrid MBR is adjusted inappropriately.


Backing up your partition tables is a good idea. See the "Final Conversion Thoughts" section of my Converting to or from GPT page for details. (The sfdisk utility referred to there is a Linux tool, but for GPT disks, the best tool AFAIK is GPT fdisk, since it includes a backup option on its main menu.) With proper backups in place, damage to your partition table is easily reversed, although you will need an emergency boot disc.


Edit: I didn't notice until I posted that socal swimmer's original post was 2.5 years ago, although NathanMac's reply is much more recent.

Link to comment
Share on other sites


  • Create New...