Jump to content

Bad partition types in GPT


bobdibble
 Share

22 posts in this topic

Recommended Posts

Question: is there a way to non-destructively update the partition types in the gpt?

 

I somewhat stumbled through a tripple-boot install, and while it is now working, the gpt side of the partitioning is a bit weird.

 

My linux partition (type 83 in the mbr) shows up as "Microsoft Basic Data" in diskutil. My XP partition (type b in the mbr) shows up as "Microsoft Reserved" in the diskutil. This makes it impossible to mount the XP partition now. (It is fat32 and used to mount before I performed the linux install and installed refit.)

 

In the boot menu, refit shows "Boot linux from" and "Boot windows from." I assume it should be putting some text there, but I don't know.

 

Anyway, is there a way to non-destructively update the partition types in the gpt so that I can deal with them correctly when in OS X?

Link to comment
Share on other sites

  • 3 weeks later...
Anyway, is there a way to non-destructively update the partition types in the gpt so that I can deal with them correctly when in OS X?

 

My partition types are screwed up too. I filed a bug to rEFIt. Because linux is not type 83 I can't boot with grub.

 

If you find something to edit the GPT table could you please inform me?

Link to comment
Share on other sites

Have you looked at the gpt command line tool? It's originally from FreeBSD and it was included in OSX. You should be able to modify the GPT table with it, but I suspect it may wipe your partitions. GNU parted also does GPT, but it'll wipe your MBR.

 

What I need is the equivalent of a reverse gptsync from rEFIt, where it overwrites the GPT structure with the structure that it finds in the MBR.

 

Right now I'm trying to hack this code to do that:

 

http://refit.svn.sourceforge.net/viewvc/re...c.c?view=markup

 

I'll let you know how it goes.

Link to comment
Share on other sites

  • 2 weeks later...

Hi all, any tip?

Also had some issue and Linux partition has lost its type: rEFIt changed it to EFI type (after a boot with a question mark)

It does not prevent Linux to boot though, but it's not very clean I think.

Partition name is lost too, so rEFIt does not show the name of the partition it intends to boot Linux on.

 

The strange thing, is that on the linux side the partition list shows all good type (ext3) and name...

 

Thanks for any tip to restore appropriate type and name.

Link to comment
Share on other sites

Hi all,

 

I put a small tool together to accurately diagnose such situations. It generates a report about the partitions listed in MBR and GPT, plus boot code and file system types found on them. (It's also intended to be useful to people that complain about rEFIt showing more icons than they expected.)

 

My resources are currently quite limited, so this has received limited testing. Any testing you can give this on an actual dual/triple boot system would be greatly appreciated. The current version can be downloaded at:

http://chrisp.de/files/Partition-Inspector-1.0b1.zip

 

BTW, the file system type detection code is also finding its way into gptsync; the backend of the above tool actually comes from the same code base as gptsync.

 

-chrisp

Link to comment
Share on other sites

Any testing you can give this on an actual dual/triple boot system would be greatly appreciated.

Thanks Chris.

Here you are.

As you'll see GPT and MBR are not in sync as I fixed the MBR through fdisk under Linux.

I'm stil interessed in fixing the GPT side, without harming anything on the disk.

Hope you can help.

 

 

*** Report for internal hard disk ***

 

Current GPT partition table:

# Start LBA End LBA Type

1 40 409639 EFI System (FAT)

2 409640 192299047 Mac OS X HFS+

3 192561192 213532711 EFI System (FAT)

4 213532712 234441607 Basic Data

 

Current MBR partition table:

# A Start LBA End LBA Type

1 1 409639 ee EFI Protective

2 409640 192299047 af Mac OS X HFS+

3 192561192 213532711 83 Linux

4 * 213532712 234441607 0b FAT32

 

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: None

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 192561192:

Boot Code: LILO

File System: ext3

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

Listed in MBR as partition 3, type 83 Linux

 

Partition at LBA 213532712:

Boot Code: Windows NTLDR

File System: FAT32

Listed in GPT as partition 4, type Basic Data

Listed in MBR as partition 4, type 0b FAT32, active

Link to comment
Share on other sites

I'm having the same problem, and was wondering if any progress has been made in figuring out a way to nondestructively edit the partition type in the GPT.

 

Current GPT partition table:

# Start LBA End LBA Type

1 40 409639 EFI System (FAT)

2 409640 170278951 Mac OS X HFS+

3 170278952 234436544 MS Reserved

 

Current MBR partition table:

# A Start LBA End LBA Type

1 1 409639 ee EFI Protective

2 409640 170278951 af Mac OS X HFS+

3 * 170278952 234436544 07 NTFS

Link to comment
Share on other sites

  • 1 month later...

So, to keep everyone updated: The situation posted by mpi is caused by a bug in GNU parted. Any partition marked as 'boot' gets the 'EFI System Partition' type for no good reason. I have added a workaround to gptsync, an updated build can be downloaded at

http://svn.sourceforge.net/viewvc/*checkou...ols/gptsync.efi.

 

That build also adds file system detection, so it will correctly label ext3 vs. NTFS vs. FAT32. More details at http://sourceforge.net/tracker/index.php?f...amp;atid=821764.

 

For the situation posted by clarkcox3 -- I don't know where partition 3 got that MS Reserved type from. The MBR looks healthy, so you should be fine. I'm afraid I can't recommend a tool to change the GPT.

Link to comment
Share on other sites

  • 1 year later...

Hi,

 

I've had the same problem and it is annoying. I downloaded the efi toolkit from Intel which has diskpart.efi program, which is sort of a FDISK. I fixed it so that it works with the tianocore.org's EFI toolkit and compiles on em64t. I added a command to change the partition type GUID, so you can use it to do:

 

select <zero-based disk number>

inspect

chtype <zero-based partition number> MSDATA

 

and it will change the partition type to Basic Data (which Macs can mount). Run gptsync after you are done as this wil put a protective partition extending the whole size of the disk in the MBR

You might find it useful to include it with rEFIt, the license clearly allows it (it's in diskpart.mak). Attached is the source and the em64t binary that runs peachy on my MacBook Pro.

 

Cheers,

Neb

diskpart.zip

Link to comment
Share on other sites

  • 1 month later...
  • 3 months later...
Here's the binary compiled for nt32, I realized that most older macs have 32 bit efi. I didn't have the time to try it, it might detonate your computer.

 

I can confirm that this method worked on a 1st gen MacBook running OS X 10.4.11 and Ubuntu 8.04

 

Yay! Thank you! :thumbsup_anim:

Link to comment
Share on other sites

  • 9 months later...

Hello

 

I downloaded the diskpart utility to be used with rEFIt because i tried setting up a triple boot on my macbook pro 3,1. I spliced my drive in two using boot camp assistant, loaded the UbuntuLive CD to run gparted to take the resulting partition and break that in two, reformatting as NTFS for windows. However, gparted put a label on the new partitions called "mstres", and after google searching it, i eventually stumbled upon some pointers that told me to use the diskpart.efi file to clear the mstres flags through the rEFIt shell.

 

However, now I'm having problems compiling diskpart.mak. I followed the readme, copying the diskpart directory to my applications folder. This follows you through my command line that i entered and the error message I got.

 

Space-Heater:~ user$ cd /applications/utilities

Space-Heater:utilities user$ nmake -f diskpart.mak

-bash: nmake: command not found

 

Is there a command i missed or is there another command that i need to use?

 

thank you!

-Outcast Valkyrie

Link to comment
Share on other sites

  • 1 month later...

My own GPT fdisk program can do what some people are asking for: It enables you to change the partition type codes in GPT partitions, thus overcoming the improper Microsoft Reserved ("msftres") tag and other problems that GNU Parted creates. It's a Linux-only program, though. (I tried compiling it under OS X, but that didn't work out too well.) It also doesn't understand hybrid MBRs, although it should at least leave the hybrid MBR alone unless you tell it explicitly to change it, so it should be safe to use to adjust the GPT side's partition type codes, so long as you don't alter GPT partitions' sizes. I make no guarantees, though. Back up your MBR before proceeding. My own limited experience is that hybrid MBRs are extremely delicate and flaky.

Link to comment
Share on other sites

My own GPT fdisk program can do what some people are asking for: It enables you to change the partition type codes in GPT partitions, thus overcoming the improper Microsoft Reserved ("msftres") tag and other problems that GNU Parted creates. It's a Linux-only program, though. (I tried compiling it under OS X, but that didn't work out too well.) It also doesn't understand hybrid MBRs, although it should at least leave the hybrid MBR alone unless you tell it explicitly to change it, so it should be safe to use to adjust the GPT side's partition type codes, so long as you don't alter GPT partitions' sizes. I make no guarantees, though. Back up your MBR before proceeding. My own limited experience is that hybrid MBRs are extremely delicate and flaky.

 

Well Rod Smith. Thank you for creating GPT fdisk program. I have written another post describing the actual problem in parted as well a small walkthrough to use your gdisk to correct the "msftres" problem. I had also sent you an email if you remember (skodabenz).

 

http://www.insanelymac.com/forum/index.php...t=#entry1192926

 

I have few doubts regarding typing any arbitary partition type GUID in GPT fdisk:-

 

For example

 

1. gdisk /dev/sda

 

Number Start (block) End (block) Size Code Name

1 62 3980213 1.9 GiB 0c01

 

(taken from your website just as an example)

 

2. Command (m for help): t

 

3. Current type is 'Microsoft Reserved'

Hex code (L to show codes, 0 to enter raw code):

 

Here lets say I type 0.

 

After this how to enter the raw code (in what format). Is it in the same way as given in wikipedia? Will a simple copy-paste be enough. Like

 

Hex code (L to show codes, 0 to enter raw code): C12A7328-F81F-11D2-BA4B-00A0C93EC93B

 

or Hex code (L to show codes, 0 to enter raw code): 0

then at the next prompt type C12A7328-F81F-11D2-BA4B-00A0C93EC93B

 

How to use this option? Please give a description similar to the GPT fdisk walkthrough you have given in your website. Thank you.

Link to comment
Share on other sites

The entry of "raw" GUIDs in GPT fdisk is awkward, in part because the GUIDs are encoded weirdly and in part because I just cobbled together the code to enter them -- I didn't expect this feature to see much use. Yours is the second request I've received for changes to this feature, though, so I do plan to improve it. As to how it works, here's a quick sample:

 

Command (m for help): t
Partition number (1-10): 7
Current type is 'Microsoft Reserved'
Hex code (L to show codes, 0 to enter raw code): 0

A GUID is entered in five segments of from two to six bytes.
Enter a four-byte hexadecimal number for the first segment, or 'R' to
generate the entire GUID randomly: EBD0A0A2
Enter a two-byte hexadecimal number for the second segment: B9E5
Enter a two-byte hexadecimal number for the third segment: 4433
Enter a two-byte hexadecimal number for the fourth segment: 87C0
Enter a six-byte hexadecimal number for the fifth segment: 68B6B72699C7
New GUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
Changed system type of partition to 'Linux/Windows data'

 

You enter the segments in the order in which they're usually displayed (for instance, on the Wikipedia entry for GPT).

 

This is obviously awkward, but that's mostly because of the length of the GUID code for manual entry. My intent was that people would use the gdisk-specific codes, which are just two bytes long and therefore much easier to type. If there's an important code missing from the ones listed as options (when you type "L" at the "Hex code" prompt), please point me to information on it and I can add the code to the program.

 

Also, I can't seem to find any e-mails from skodabenz on my system. Was this a recent e-mail? If not, it's conceivable that I deleted it and don't recall its contents. If it was recent, though, it seems to have gotten lost.

Link to comment
Share on other sites

I can't seem to find any e-mails from skodabenz on my system. Was this a recent e-mail? If not, it's conceivable that I deleted it and don't recall its contents. If it was recent, though, it seems to have gotten lost.

 

I sent you the message to you through the Sourceforge.net page for GPT fdisk ( https://sourceforge.net/sendmessage.php?touser=2472630 ). Sorry, actually it was sent from this address "opensourcelinux@users.sourceforge.net", not from any skodabenz. My name should appear either as Keshav or Keshav P R in your mailbox. Please check. Thank you.

Link to comment
Share on other sites

To Rod Smith

 

I do not understand the meaning of little-endian byte order explained in Wikipedia GPT (http://en.wikipedia.org/wiki/GUID_Partition_Table) page :-

 

The GUIDs in this table are written assuming a little-endian byte order. For example, the GUID for an EFI System partition is written as C12A7328-F81F-11D2-BA4B-00A0C93EC93B here, which corresponds to the 16 byte sequence 28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B — only the first three blocks are byte-swapped.

 

Is this anyway connected to what you explained in your previous post? :-

 

The entry of "raw" GUIDs in GPT fdisk is awkward, in part because the GUIDs are encoded weirdly and in part because I just cobbled together the code to enter them -- I didn't expect this feature to see much use.

 

Why are the GUIDs not written to the disk in the same way as the given input? Why should the bytes be swapped? What are little-endian and big-endian? Why gdisk will work only in little-endian computers? How can we tell whether the OS I am running or the processor I am using is little-endian or not? If Linux-Intel or Linux-AMD is little-endian, is Linux-PowerPC or Linux-SPARC little-endian? Is it dependent on the OS (software) or the processor (hardware) or both? Please explain.

Link to comment
Share on other sites

I sent you the message to you through the Sourceforge.net page for GPT fdisk ( https://sourceforge.net/sendmessage.php?touser=2472630 ). Sorry, actually it was sent from this address "opensourcelinux@users.sourceforge.net", not from any skodabenz.

 

I don't see such a message. I just checked, and was able to send e-mail to myself via SourceForge, so I don't know why I didn't get your e-mail.

 

I do not understand the meaning of little-endian byte order explained in Wikipedia GPT (http://en.wikipedia.org/wiki/GUID_Partition_Table) page :-

 

Little-endian and big-endian are two different ways of encoding multi-byte numbers. For instance, suppose you want to represent the (decimal) number 258. In hexadecimal, humans would normally represent it as 0x0102. This is a big-endian representation. In a little-endian representation, the byte order is reversed, so (decimal) 258 would be 0x0201. This is weird from a human perspective, but some CPUs use little-endian encoding natively for technical reasons that I don't claim to understand. The common x86 and x86-64 CPUs both use little-endian representations. PowerPC can use either big- or little-endian values, although I believe that MacOS for PowerPC uses big-endian representations.

 

The GUIDs in this table are written assuming a little-endian byte order. For example, the GUID for an EFI System partition is written as C12A7328-F81F-11D2-BA4B-00A0C93EC93B here, which corresponds to the 16 byte sequence 28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B — only the first three blocks are byte-swapped.

 

Is this anyway connected to what you explained in your previous post? :-

Why are the GUIDs not written to the disk in the same way as the given input? Why should the bytes be swapped? What are little-endian and big-endian? Why gdisk will work only in little-endian computers?

 

Yes, the two are related. GUID encoding is weird, in part, because it mixes big-endian and native-endian encoding, so it could be entirely big-endian or a mixture of big- and little-endian, depending on the CPU. To further confuse matters, GPT was designed around little-endian encoding, so the GUIDs stored in GPT data structures are a mixture of big- and little-endian data structures, even on big-endian CPUs. Each block of GUID data is reversed (or not) within its own block; the order of the blocks is constant. This means that the code for GPT fdisk, or any other program that manages GPTs, must know what endianness the CPU it's running on uses and swap the byte order of some blocks of values but not other blocks of values. It also means that some values read from the disk structures (even some non-GUID data) must be byte-swapped when read from the disk for some CPUs but not for others. Currently, GPT fdisk is written for little-endian CPUs only. Adapting it for CPUs that use either byte order will require adding code to do the appropriate byte-order adjustments in various places. Testing it will require access to an appropriate system. I've got an old PowerPC iMac, but its Linux installation is currently only semi-functional, which is why I put off this task.

 

How can we tell whether the OS I am running or the processor I am using is little-endian or not? If Linux-Intel or Linux-AMD is little-endian, is Linux-PowerPC or Linux-SPARC little-endian? Is it dependent on the OS (software) or the processor (hardware) or both? Please explain.

 

Offhand, I don't know of a Linux or OS X command that returns this information directly for the user. As I said, x86 and x86-64 CPUs are little-endian. I think that Linux for PowerPC is big-endian, and I'm pretty sure that OS X for PowerPC is big-endian. Wikipedia says that SPARC is big-endian, except for version 9, but I have no way of verifying this. Endianness is generally hardware-dependent, but some CPUs (such as most PowerPC CPUs) can use either byte ordering.

Link to comment
Share on other sites

  • 3 weeks later...

Hey guys! I’ve found a free 64 bit Windows partition manager by accident. I downloaded it and used it. This software was amazing and easy to use. The most important is that it is free here I would like to share it with you. Following are copied from the website:

Partition Wizard Home Edition is a free partition manager designed by MT Solution Ltd. It supports 32/64 bit Windows Operating System including Windows XP, Vista and Windows 7. Home users can perform complicated partition operations by using this powerful but free partition manager to manage their hard disk partition such as Resizing partitions, Copying partitions, Create partition, Delete partition, Format partition, Convert partition, Explore partition, Hide partition, Change drive letter, Set active partition and Partition Recovery.

 

Partition Wizard comes absolutely free for Home user and free of charge for business user. Home users, business users, system administrators can easily use this Windows based software to manage their disk partitions. Download it for free from http://www.PartitionWizard.com and enjoy the new technology and new experience of Partition Wizard.

 

More information at http://www.partitionwizard.com

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 months later...
An update: The latest version (0.3.2) of my GPT fdisk program can now be compiled on Mac OS X. (I've got a binary available for download.) Check its entry on my home page or its Sourceforge page for more details.

 

I have Ubuntu running on a USB HDD. On my MacBook Pro, I am able to use refit to boot it. But on my iMac, I am not able to. Refit shows the linux icon but claims to have a Missing OS. When I run partition inspector on the iMac it shows this.

*** Report for internal hard disk ***

Current GPT partition table:
#	  Start LBA	  End LBA  Type
1			 40	   409639  EFI System (FAT)
2		 409640	976510983  Mac OS X HFS+

Current MBR partition table:
# A	Start LBA	  End LBA  Type
1			  1	   409639  ee  EFI Protective
2 *	   409640	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: None
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+, active

 

As you can see, it doesn't show the Linux drive or any other additional drive. When I run the refit gpt sync, it says it is already sync. Will your app help in my situation?

 

Thanks,

 

Calvin

Link to comment
Share on other sites

  • 1 month later...
An update: The latest version (0.3.2) of my GPT fdisk program can now be compiled on Mac OS X. (I've got a binary available for download.) Check its entry on my home page or its Sourceforge page for more details.

 

Rod, is this your preferred method of donation? I may not have lots of money but I really want to give you something for creating such a unique and important tool. This was very helpful for me. I can't believe that parted still has this bug and that there still aren't better GPT/hybrid tools available.

Link to comment
Share on other sites

 Share

×
×
  • Create New...