Tag Archives: macdrive

hello world, meet gpt-surgeon

gpt-surgeon has a new home on Launchpad! Look for it at https://launchpad.net/gpt-surgeon. Downloads compliant with the Launchpad release scheme (GPG-signed tarball) available here: https://launchpad.net/gpt-surgeon/+download

I’ve decided to go with GPLv2 as the licensing scheme, no copyright assignment required, to keep this simple utility open and available to the public with a minimum of hassle and a maximum of fresh code.

gpt-surgeon will still be available here on Bat Country for a time, but fresh development and new versions will be on the Launchpad site. This version will be frozen as soon as the Launchpad version is available.

Tagged , , , , , , ,

more on: invalid BS_jmpBoot in boot block: 000000

I’ve been getting a lot of comments that say “invalid BS_jmpBoot in boot block: 000000” happens with  Apple’s Boot Camp HFS drivers from Snow Leopard as well as MacDrive. The act of assigning a drive letter to the partition seems to cause the GPT corruption. This would seem to make it a Windows issue. I do not speak for my employer in any official capacity, but when my current high-priority tasks are done, I’ll ask around at work and see if anybody knows anything about this issue.

Meanwhile, keep sending in your experience reports! The more data, the better.

***

update: Comments have been turned off for this post; all questions, comments, suggestions, and support requests about gpt-surgeon must be submitted through the gpt-surgeon LaunchPad site and should be accompanied with disktype reports.

Tagged , , , ,

invalid BS_jmpBoot in boot block: 000000

MediaFour‘s MacDrive (7.2.6) keeps screwing up the GPT on my external GPT-formatted drive. It has one HFS+ partition and one 200 MB EFI system partition, and when I boot my iMac into Windows (Vista SP1 x86), mount the drive, and then boot back into Mac OS X (10.5), I usually find that OS X won’t recognize the HFS+ volume any more. The characteristic error is an ignore/eject/format unrecognized dialog after OS X login, and “invalid BS_jmpBoot in boot block: 000000” from Disk Utility when trying to repair it.

It seems that the GUID for the HFS+ volume is changed from {48465300-0000-11AA-AA11-00306543ECAC} (HFS+) to {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} (“Microsoft Basic Data”). Windows doesn’t have any trouble mounting it as long as MacDrive is installed, it’s OS X that has the problem. I was able to fix the GPT by changing the GUID back to what it should be, at which point the drive was recognized by OS X, and found that the actual HFS+ file system was unharmed. I wrote most of a GPT editor in the process, and if Mediafour doesn’t fix MacDrive soon, I may end up turning it into a one-click GPT fixer.

***

update:

Here’s the tool I used to fix my own disk: gpt_surgeon.py

It’ll need Python 2.5 or higher, and has only been tried in OS X on my own machine. Run it with no arguments or look at the code for a usage statement. The repair process goes like this:

First, list the partitions on your disk to figure out which one needs to be relabeled with the right filesystem type. If you don’t know what your disk device path is, go look in Disk Utility or System Profiler or run diskutil(8) with its list option. The path for my external disk is /dev/disk1.

$ ./gpt_surgeon.py list /dev/disk1

Read MBR and GPT from /dev/disk1.
partition 0:
     type: EFI System
     name: u'EFI System Partition'
    flags: 0x00000000
partition 1:
     type: Microsoft Basic Data
     name: u'Untitled'
    flags: 0x00000000

Note the partition that says “Microsoft Basic Data”. Assuming that you had a single non-system partition on the disk, and that the partition was HFS+ before MacDrive got to it, this is probably that partition. In my case, it’s partition 1. Remember the number; you’ll need it in the next step.

If you have multiple data partitions on the disk, especially if one of them is actually a Windows data partition, you should use something like disktype to check what filesystems are present in each partition, so that you don’t accidentally relabel the wrong one.

If you have any other partitions from this disk mounted, unmount them now.

You’ll need to run with sudo to get the privileges necessary to actually repair the GPT on disk.

$ sudo ./gpt_surgeon.py repair /dev/disk1 1

Read MBR and GPT from /dev/disk1.
Changing type of partition #1 on /dev/disk1 to HFS+...
    Opened /dev/disk1 for writing.
    Wrote MBR.
    Wrote GPT header.
    Wrote GPT entries.
    Closed /dev/disk1.
Done.

And this is what the disk’s GPT should look like afterwards. Your HFS+ partition should be mountable now.

$ ./gpt_surgeon.py list /dev/disk1

Read MBR and GPT from /dev/disk1.
partition 0:
     type: EFI System
     name: u'EFI System Partition'
    flags: 0x00000000
partition 1:
     type: Apple HFS+
     name: u'Untitled'
    flags: 0x00000000

***

second update: commenter James let me know that Christophe Grenier‘s TestDisk utility can also be used to fix this problem.

***

third update: here’s a video walkthrough of the process. For people who have Flash turned off for some reason, please see the QuickTime version of the walkthrough.

***

last update: gpt-surgeon is opening up! Thanks to all who submitted usage reports, suggestions, failure data, and proposed patches. I hope you’ll find future versions at least as useful. Comments have been turned off for this post; all questions, comments, suggestions, and support requests about gpt-surgeon must be submitted through the gpt-surgeon LaunchPad site and should be accompanied with disktype reports.

Tagged , ,