Q: Repairing Boot Camp after creating new partition

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/message/24073035#24073035#24073035

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.

Oops. Try disk instead of rdisk.

Christopher Murphy wrote:

 

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.

/ScanOs

This option scans all disks for installations that are compatible with Windows Vista or Windows 7. It also displays the entries that are currently not in the BCD store. Use this option when there are Windows Vista or Windows 7 installations that the Boot Manager menu does not list.

This is what I was suggesting. From the oft-referenced http://support.microsoft.com/kb/927392

Option key should also show various bootable disks.

I would also be curious about what fdisk would show on /dev/rdisk0.

Remove the code from the disk's MBR with this command. Have backups and be certain you get it correct or it'll quickly (effectively) erase the drive.

sudo dd if=/dev/zero of=/dev/diskX bs=440 count=1

This will write zeros onto the first 440 bytes of LBA 0, to diskX, thus removing only the boot code, not the MBR partition map. Now, one small gotcha is that it might refuse to let you do this, suggesting "resource busy". If so, maybe enlarge the command text in TextEdit first, and then either print it out or copy it exactly, and then see if it'll work rebooted in single user mode (command-s at the startup chime). If that still doesn't work, then you'll need to do it from Recovery HD and find the hidden Terminal application in one of the drop down menus.

Warning, anytime you reboot, the designation of a disk can change. That is, this boot the drive is /dev/disk0 but if you boot single user mode or from Recovery HD, it might become /dev/disk1 or even /dev/disk10. So you need to make really sure you're using the above command with the right disk number. That's why I wrote it as diskX above instead of disk0. Use:

diskutil list

first to make sure.

Oh and the disk to remove the code from is the internal drive that originally had Windows on it, but no longer does. You only want code on the drive that has Windows on it.