GUID?! --==> bacame MBR?! wtf?

[aniphreak]

i formatted the whole disk to GUID

 

then partitioned, installed leopard.

 

after i made a partition for a windows installation

 

then i installed windows 7. pdc

 

 

then changed it back to leopard as the active partition. it worked fine actually.. then i just realized that its already a mbr and not guid...

 

 

whaaa... how can i change it back?

[Hagar]

I experienced this a lot whilst experimenting with the EFI System Partition.. messing with the partitions seems to cause disk util to see the drive as mbr. Although GPT can contain a legacy mbr for just such purposes as booting non-GPT OS'es, I have no good explanation why the mbr should become "dominant" in such situations.. Have you tried gptsync?

[aniphreak]

Have you tried gptsync?

 

*edit*noobish*

 

no i have not... what does it do anyway?

[aniphreak]

any solution for this!?

[aniphreak]

partition inspector (is that the gptsync?) with leopard installer partially fix it (i think... dunno)

 

but its still the same on disc utility... i really dont know how to bring it back to guid...

 

 

*** Report for internal hard disk ***

 

Current GPT partition table:

# Start LBA End LBA Type

1 40 409639 EFI System (FAT)

2 409640 133702719 Mac OS X HFS+

3 133964864 210282127 Basic Data

4 210544272 976510983 Mac OS X HFS+

 

Current MBR partition table:

# A Start LBA End LBA Type

1 1 409639 ee EFI Protective

2 409640 133702719 af Mac OS X HFS+

3 * 133964864 210282127 07 NTFS/HPFS

4 210544272 976510983 af Mac OS X HFS+

 

MBR contents:

Boot Code: Unknown, but bootable

 

Partition at LBA 40:

Boot Code: None (Non-system disk message)

File System: FAT32

Listed in GPT as partition 1, type EFI System (FAT)

 

Partition at LBA 409640:

Boot Code: Unknown, but bootable

File System: HFS Extended (HFS+)

Listed in GPT as partition 2, type Mac OS X HFS+

Listed in MBR as partition 2, type af Mac OS X HFS+

 

Partition at LBA 133964864:

Boot Code: Windows BOOTMGR (Vista)

File System: NTFS

Listed in GPT as partition 3, type Basic Data

Listed in MBR as partition 3, type 07 NTFS/HPFS, active

 

Partition at LBA 210544272:

Boot Code: Unknown, but bootable

File System: HFS Extended (HFS+)

Listed in GPT as partition 4, type Mac OS X HFS+

Listed in MBR as partition 4, type af Mac OS X HFS+

 

 

any bright ideas out there?

[Mark Turner]

Thought I'd add that this same thing happened to me...

 

Did you solve this problem?

[srs5694]

Some basics on MBR and GPT:

 

MBR is defined by a single sector of the disk (sector #0, the first sector), which contains boot loader code and space to define up to four partitions (the four "primary" MBR partitions).

 

GPT includes a "protective MBR" and two copies each of GPT header data and GPT partition definitions. A normal GPT protective MBR is a valid MBR that contains a single disk-spanning partition of type 0xEE. The role of the protective MBR is to protect the disk from damage by GPT-unaware disk utilities.

 

Some configurations, particularly on multi-boot Windows/MacOS systems, employ a "hybrid MBR," in which the protective MBR is changed so that the 0xEE partition doesn't span the whole disk, and duplicate definitions for one to three GPT partitions are added to the MBR. This enables GPT-aware and GPT-unaware OSes to share the disk, but hybrid MBRs are klunky, non-standard, and delicate.

 

Given the data presented, my suspicion is that the disk was originally set up using a hybrid MBR, and something then eliminated the 0xEE partition from the hybrid MBR. Most OSes, when presented with such a disk, will see it as being MBR-only; they'll ignore the GPT data.

 

There are several ways to recover the GPT configuration, but all of them pose a risk of failure, which could result in data loss:

 

• Manually add a 0xEE partition to the disk using a suitable disk utility, such as fdisk. Not all partitioning tools can do this, though. Also, some OSes and boot loaders are picky about the 0xEE partition; it may need to be the first of the four primary partitions and/or start at the second sector (sector #1, as numbered starting from 0). I don't know offhand if the OS X fdisk utility can do this job. I'm pretty sure that the GUI Disk Utility can't do it.
  
• Use my GPT fdisk program to convert MBR to GPT and then create a new hybrid MBR for the disk. Alternatively, if enough of the GPT data remain on the disk, GPT fdisk will detect it and present you with the option of using it directly. You'd then need to create a new hybrid MBR for the disk.
  
• Use the FreeBSD gpt program or the Windows gptgen program to convert MBR to GPT, then use the gptsync utility (I have no URL handy) or GPT fdisk to create a new hybrid MBR configuration. I can't promise this would work with old GPT data already present, though; I don't know how gpt or gptgen would react to such a configuration.
  

 

Another option is to simply leave it be. OS X boots and runs fine from MBR. Although GPT does have a few advantages, there is wisdom in the saying "if it ain't broke, don't fix it." The biggest risk to leaving it alone, IMHO, is the risk that, if you make partitioning changes on the MBR side, some disk utility you use in the future might notice the (now obsolete) GPT data and try to use it, thus damaging your disk. One way to avoid this risk would be to wipe out the GPT data. GPT fdisk includes an option to do that -- but there's a small risk that such an attempt will damage data in your first and/or last partitions.