Repairing Boot Camp after creating new partition

Christopher Murphy,

may I ask what your views are on this (from an earlier post)? Would it be likely to work? Thanks.

"So normally in these situations the only official way to deal with this is to format the drive and re-install everything.

Obviously OSX still boots but I'm assuming that disk utility will refuse to allow you to delete the Bootcamp partition.

Therein lies the problem.

Have a go at that first.

If it doesn't there may be a way to delete the partition with gdisk and to create a new protective MBR.

This may fool OSX into thinking that there was never a Windows installation and it may then allow you to stretch the Macintosh HD back to the full size of the disk again.

Thereby allowing you to start again.

As I say this is not official and I haven't tried it before but it may work."

I also got aproblem with my windows.

Here is my filesystem:

thanks for help.

Can you describe the problem in a bit more detail?

Please run the following commands.

sudo gpt -r -vv show /dev/rdisk1

sudo fdisk /dev/disk1

I transferd the bootcamp partition via winclone to an external thunderbolt drive cause I need the space on my Macbook SSD.

After that windows isn't booting anymore.

Problem is, windows is not booting. only _ cursor blinking.I

waffenschmiede wrote:

I transferd the bootcamp partition via winclone to an external thunderbolt drive cause I need the space on my Macbook SSD.

After that windows isn't booting anymore.

Problem is, windows is not booting. only _ cursor blinking.I

Windows won't boot from an external drive so stop trying.

you can't install windows with the normal installer on an external drive. But booting is no problem.

I think it is the problem with only from the first four partitions can boot.

waffenschmiede wrote:

you can't install windows with the normal installer on an external drive. But booting is no problem.

I think it is the problem with only from the first four partitions can boot.

OK, keep trying.

In the fdisk output, you have a bootable entry from 411648. I am not sure how you have an entry at 409640 (size 2008). If the 411648 is the correct location for your Windows installation, it should boot.

In this thread, Christopher has mentioned the dd command. You can try that to see what is in this part of the disk.

I suspect the entry should start at 409640. I have not seen such gaps in GPT entries very often unless some utility (like gdisk/gpt) was used to create one by hand.

Here is the link to that command/thread - https://discussions.apple.com/thread/5646583?answerId=24073035022#24073035022

Would it be likely to work?

When the GPT and MBR aren't sync'd, Disk Utility can get confused and how that confusion manifests might be version specific. It's just a guess, but I think it would let you delete the Windows partition and it would then probably replace the hybrid MBR with a protective MBR. How I don't think Boot Camp Assistant is smart enough to know what to do with all of that unallocated space: I suspect it won't permit growing the OS X volume to use that free space, nor will it permit turning it into a new Boot Camp volume. So you're sorta stuck at this point. I also don't know for sure that with a broken Windows volume, if Boot Camp Assistant will permit deleting it, or if it too gets confused.

If you use gdisk to delete the Windows volume and create a new protective MBR, I still think Boot Camp Assistant won't permit resizing the OS X volume. It's possible that Disk Utility will, but I've seen some cases where it nukes Recovery HD in the process. Apple has chosen a weird way of doing all of this, where resizing the OS X volume also means actually copy/relocating the 620MB Recovery HD. And sometimes that fails so instead they just delete it. I have no idea why they don't either put Recover HD in front of the OS X volume (in GPT #2), or why they don't just leave it at the end of the drive during resizing rather than treating it like a conjoined twin that must somehow travel along with OS X at all times.

transferd the bootcamp partition via winclone to an external thunderbolt drive

Each Mac's firmware seems a bit different how the CSM-BIOS will handle external booting. Some simply won't permit it. Over on the Mac Rumors forum somewhere, somebody figured out how to do this on a Thunderbolt drive by compelling Windows to create a small FAT32 "boot" volume on their internal drive (I think this is called a system partition? sorta confusing) and then the main Windows NTFS volume (which I think they call a boot partition, yes more confusion) is on the external. Basically the BIOS is too stupid to make the jump, so a basic OS has to be booting first and then it can jump over to the external to complete the process. It's not altogether different than a Recovery HD that boots encrypted (FileVault 2) OS X volumes.

Anyway, it's not supported by Apple to do this. You won't find any easy Apple tools to make it happen. And it gets really tricky if the external drive is bigger than 2TB, which is not applicable to your case so I think it should be possible but it's going to take some work. Chances are your best bet for this external is to partition it strictly as MBR. There's no real advantage for it to be hybrid MBR. Then it's resizeable with Windows tools without problems - just make sure never to touch it with Disk Utility or Boot Camp Assistant.

On his disk1, GPT 1 is the EFI System partition starting at LBA 40. It ends such that the next free sector is LBA 409640 is not 1MB aligned, and these days it's more common to align on 1MB boundaries and 411648 is 1MB aligned. So there's 2008 sector gap of free space between GPT 1 and GPT 2. This is fine.

GPT 2 start LBA agrees with MBR 2. And MBR 2 is flagged bootable. The reason why it's not working could be one of two things, the aforementioned firmware limitation, or the fact disk0 still has boot code in LBA 0. That boot code tells the firmware to jump to a specific LBA *on that same disk* which now doesn't contain Windows. On a real BIOS, there's a setup interface to choose which disk to boot from but we don't have that with CSM-BIOS on Macs. So only one disk can have BIOS boot code, and also the firmware's CSM must be of the type that will look for this boot code on other drives not just internal ones.

To confirm/deny there is boot code on disk0 without changing anything:

sudo dd if=/dev/rdisk0 bs=440 count=1 2>/dev/null | hexdump -C

That will read the first 440 bytes of LBA 0, strip out errors, and then format them with the hexdump command. If there's boot code there, for sure the CSM-BIOS will use that and then get stuck just as is being described. Next would be to check if it's on the other drive by using the same command, but changing rdisk0 to rdisk1.

Christopher Murphy wrote:

The reason why it's not working could be one of two things, the aforementioned firmware limitation, or the fact disk0 still has boot code in LBA 0. That boot code tells the firmware to jump to a specific LBA *on that same disk* which now doesn't contain Windows.

bootrec / scanos and Windows Recovery Console can also be used to scan/fix the MBR.

nothing happens with the command.

bootrec / scanos and Windows Recovery Console can also be used to scan/fix the MBR.

Not applicable, there's nothing to fix. You're not understanding what I wrote. The internal disk, if it had Windows on it, probably still has boot code in its MBR boot strap region. That needs to be removed because on Macs only one disk can have BIOS boot code.