Unable to boot up in bootcamp after installing Mountain Lion

Bootrec.exe Windows Recovery Environment

http://support.microsoft.com/kb/927392

Yep, that's the process I used. Judging from the lack of files on the disk when accessing from Paragon, I'd say somehow the file allocation table on that partition had got corrupt. I'm sure it would have been recoverable with some work but there wasn't anything that important on there to go to that much trouble.

Yes that was why I think I first suggested the "sledge hammer" approaches.

CampTune does support making a backup image and because it can resize partitions also knows the proper entries and how to do the edits. I figure if it was doable CampTune and Bootrec would be my choices.

If you suspect directory damage to the NTFS volume, the MBR does need to be fixed first (which you did), but before you can replace the bootloaders or rebuilt BCD, the NTFS directory must be repaired. In order I would try

chkdsk

chkdsk /p

chkdsk /r

For each you should get a bunch of text about what the state of the disk is in. If you get a non-zero value for the result:

0 KB in bad sectors

All bets are off and we need to move to smartmontools, which accesses the built-in SMART diagnositcs on the disk. It's not a bad idea to do this anyway...

@C. Murphy

I perfectly understand the difference between GPT and MBR. I have been using PCs since MS-DOS 1.0 and Apple OS since the Apple II, so I have a very good understanding of all this.

What I know is that when your bootcamp partition is messed up with/by OS X, your best bet is, if the data is still there (hence my suggestion to check with Disk Utility, just to see if the partition is there if it doesn't mount on the desktop) is to back it up, go back to a CLEAN OSX state with just one OS X partition (apart from the hidden recovery one), recreate the bootcamp partition and restore the data which is what Winclone allows you to do in a snap.

Yes disk utility is useless with NTFS partitions, but that was not the point. The point was to check if the partition is still there so that you can actually back it up and recreate the bootcamp partition from scratch.

This SOLVES the problem for good with no need to mess up with terminal and no guarantee that you are not going to make things worse, or worse, lose the bootcamp partition altogether, with the additional bonus of having a backup of your bootcamp install, which is always handy

I would NEVER touch partition info without having a backup of the info on the drive, and that applies to both the OS X partition and the bootcamp partition.

I find it very optimistic (if not irresponsible) to give resizing command line info to a user who has NO BACKUP of either partition, as if things go wrong well or if you've made a mistake - as it has already happened - well, you have lost everything.

What I don't understand is PSEUDO advice here, not the underlying issues or the ways to solve them simply and safely.

As far as I can see, the problem is still not solved as the OP still can't select the right partition to boot from within OS X or even using the ALT key.

Good luck with all the fun command line experimentation, I hope no one gets burt in the process🙂.

EDIT: just missed one page, glad to see the problem was solved... by removing and recreating the bootcamp partition. Unfortunately by then the data was corrupt.

McManni wrote:

Disk Utility, just to see if the partition is there

This is pointless because the CSM-BIOS and Windows only see the MBR. The presence, or lack thereof, of a Windows partition in Disk Utility does not mean anything. If present, the GPT data can be wrong while the MBR data can be correct. If not present, the MBR data might still be present and be correct. One cannot determine any of this with Disk Utility at all.

This SOLVES the problem for good with no need to mess up with terminal and no guarantee that you are not going to make things worse, or worse, lose the bootcamp partition altogether

Somehow you're under the impression that editing partition maps somehow can alter contents inside of partitions. It doesn't. Editing the MBR is always a single sector edit only.

It's a little silly to say you want backups before editing partition maps, an operation vastly more benign than even booting which alters thousands of sectors. The user should have a backup no matter what, not merely when altering partition maps.

Your recommended procedures is significantly more dangerous because it requires the destruction of all data on the original disk, depending exclusively on the viability of a backup and its proper restoration. My method leaves the original data and the backup intact. No data is destroyed. My method is an attempt to understand and repair the problem, rather than just start over - a process that takes hours and isn't guaranteed to work either.

The fact of the matter is, you're merely more familiar with your sledgehammer approach to fixing this problem, and comparatively unfamiliar with alternatives that are not nearly as invasive or destructive.

Last, you assert that my suggestions didn't help the "OP" when I didn't even contribute to the thread until after the OP said his problem was fixed! My first post was solicitation of information, not recommendations.

I'm curious how it's even possible for Mountain Lion to make these kinds of alterations to either partition maps or to Windows volumes - and thus far that's not answered in any of this. What's needed is someone who can reproduce the problem, with before and after recordings of both the MBR and GPT.

Given the hybrid MBR is non-standard, incompatible with the UEFI spec, and departs from Apple's own developer notes proscribing their usage let alone subsequent editing of the GPT once the MBR is no longer a single entry PMBR (Disk Utility itself violates this proscription), there really is no good way to support this. It could even be 3rd party utility related - I've seen that a lot.

You are either playing dumb, or you have an agenda that I do not get.

Using disk utility in this case has only one function: if the user isn't showing mounted partitions on the desktop, and if the bootcamp partition doesn't appear in the startup pref, it allows to make sure it is still there. That's it. Nothing more, nothing less.

Regarding editing partition maps, yes it might be only one sector, but when it doesn't go as planned, it can actually erase a whole partition, or corrupt the whole disk. If it hasn't happened to you, you have just been lucky or you haven't done this often enough. This is the difference between the theory and the practice.

Yes in theory you are only changing one sector. But if something is corrupted, or if there is a mistake in the command (especially when the user typing it doesn't understand it), the risks are high in my opinion.

You are right to say that we should have a backup anyway, but I stick to my position regarding backing up BEFORE touching any partition information. Some sectors are more important than others...

It is precisely because the hybrid bootcamp partition is NOT standard that most tools are inefficient or can corrupt things further.

When you say that this shouldn't happen when upgrading from Lion to Mountain Lion, I agree with you, but you are either inexperienced or naive if you think that things don't happen when they shouldn't. It's probably due to a non tested pre-condition, or to a combination of utilities, but bad things do happen when upgrading OSes, and that's another reason for having a backup of all partitions before doing so.

Anyway, you are obviously coming from a theoretical position, and I'm more pragmatic. You might be right in theory, but I took me a few minutes to backup/restore the partition (I do something else while the data is written/read back), while many hours later you're still discussing the why. My method might be "sledgehammer", but it's based on experience. When things can go wrong, they will, that's why a recent backup is usually the fastest way to solve these kind of issues. It's of course better when the backup has been done just prior to the upgrade...

Signing off now because I don't think we're getting anywhere.

Regarding editing partition maps, yes it might be only one sector, but when it doesn't go as planned, it can actually erase a whole partition, or corrupt the whole disk. If it hasn't happened to you, you have just been lucky or you haven't done this often enough. This is the difference between the theory and the practice.

Yes, if you use Disk Utility to do the editing, because integrated into it, without any choice from the user, is the potential for it to also format a partition. fdisk, gpt, gdisk, do not have this ability at all in their code. Editing partitions with these tools will not in itself cause corruption. If you tell them to delete a partition, it merely removes the partition entry from the partition map. Nothing inside the partitions is even read from let alone written to. Restoring partition entries restores access to otherwise unmodified file systems.

I stick to my position regarding backing up BEFORE touching any partition information

It's not an unreasonable position, I've never suggested otherwise. However, for you to be consistent, your posistion should include backing up before using Boot Camp Assistant as well. It not only modifies both the MBR and GPT, but it significantly modifies a live file system as well. That's thousands of times more risky of an adventure than altering the active flag on a single sector.

the hybrid bootcamp partition is NOT standard

Your terminology is flawed. The bootcamp partition itself, is a Windows NTFS volume and it's quite standard and well understood, albeit proprietary. It is also not hybrid. What is hybrid is the MBR, defined as an MBR with more than one entry, on a disk that also has a valid GPT.

Anyway, you are obviously coming from a theoretical position, and I'm more pragmatic.

I've done all of these kinds of edits on live production systems hundreds of times, and many more hundreds of times on VM. So obviously you're wrong.

I took me a few minutes to backup/restore the partition (I do something else while the data is written/read back), while many hours later you're still discussing the why.

Only because it's a technique most people are unfamiliar with. If you're familiar with identification of the actual problem with proper tools, it takes seconds to minutes to fix without destruction of the original data, while also depending exclusively on the proper restoration of a properly prepared backup - i.e. high risk.

My method might be "sledgehammer", but it's based on experience.

Or the lack of experience with safer faster alternatives. Most problems with Boot Camp are tied to the MBR being nuked. Recreating it is rather straight forward if you know how to do it. If you don't have any additional partitions than a Mac OS and Windows partition, gptsync in rEFIt or rEFInd can fix this and is GUI based. I prefer using gdisk because I come across users who have more partitions than can be stuffed in an MBR in the conventional way.

Signing off now because I don't think we're getting anywhere.

I'm pretty sure you've said this before.

That's the whole point. You are trying the get people who have no understanding of what you're asking them to do, without them having any safety net. You made some mistakes in the instructions you gave. They can make mistakes typing them. It's just arrogance to behave the way you do.

And by the way, I do make a backup before I start bootcamp partition. And I occasionally use refit as well, although it has its own issues.

The fact that you are technically right doesn't mean you are not procedurally wrong.

I was just advocating a solution that anyone can use, all the time. And that I believe is safer than what you are asking users to do.

You are playing apprentice sorcerer with tools that can potentially nuke all the data.

Have a good day.

You are trying the get people who have no understanding of what you're asking them to do

People are already using tools they have no understanding of at all anyway. And I'm not trying to get them to do anything they haven't already asked for anyway.

You made some mistakes in the instructions you gave.

It was not an entry error, but an omission, and it was benign. Had Caillin chosen the wrong option, user data would have been in no way adversely affected. He had posted his original GPT and MBR to the forum, even if he'd completely deleted all partition data, it could easily be restored and again user data would have been in no way adversely affected.

They can make mistakes typing them.

This is a pointless assertion as it applies to any situation. People have made honest mistakes on these very forums, using Disk Utility, that have made Windows unbootable with no GUI means of restoring functionality, when the utility arguably should have disallowed the user from modifying the disk's GPT in the first place. I filed a bug on this behavior, BTW.

It's just arrogance to behave the way you do.

Versus ignorance and condescention? I will accept arrogance over those.

I believe is safer than what you are asking users to do.

Your belief is flawed. It's demonstrably safer to repair than to destroy data.

You are playing apprentice sorcerer with tools that can potentially nuke all the data.

This is FUD, and you're simply wrong. The specified tools have no formatting capability or ability to alter data inside partitions. Their function is transparent and open source, there is nothing sorcerer about any of them. But I invite you to describe, exactly and in detail, how the tools can potentially nuke all data so that I can correct your remarkably flawed reasoning.

What you've recommended, in fact, DOES nuke the user's original data. Your method calls for copying the ship inside a black box, destroying the original ship, and then extracting the ship from its box hoping it's viable, all to solve a 1/2" hole. That you're more comfortable with the replace vs repair technique, considering a backup should exist in either case, reflects on your preference.

You assume ignorance. There is no condescendance on my part, except maybe in reaction to yours.

You keep using as premises that in theory your method is harmless. I am saying that in practice, it is not. Simply because we are dealing with computers, and there are always things we didn't think about, or things that shouldn't happen. Like corrupting the mbr and making a bootcamp partition non bootable when upgrading the OS. The fact that it shouldn't happen doesn't mean that it doesn't. Just like your in theory harmless command lines.

You make it sound as if it was by design, like you would only allow yourself to make mistakes in harmless situations, but it was simply lucky that you made a mistake on a non destructive instruction. That doesn't mean it couldn't have happened with a destructive one. Or that a theoretically harmless command couldn't trigger an unforeseen exception. You are just so confident in your technological knowledge that you can't even see that the possibility is always there.

Again, your arrogance comes from the fact that you do not realize that your knowledge is not a protection against everything, especially when you're working on a system that is not yours. On the contrary. Unfortunately computer maintenance is not an exact science, even if you naively seem to believe the contrary. Also you seem to forget that if you make a mistake, or if the user makes a mistake, then they are dependant on you (or someone else) to repair it (supposing it's still possible).

When the bootcamp partition is accessible, and when the data is readable, if you back it up with Winclone and then go back to a healthy single partition system, before recreating the partition and restoring its content, you have not taken any risk with the data. What's there is backed up. There is no risk to lose it. If it wasn't there to be backed up, well, you haven't lost anything. You analogy with a ship is ridiculous. A backup is not a black box. It's a backup.

Winclone is also intelligent enough to copy a fresh MBR if necessary after restore.

You just don't understand the beauty of simplicity because you are attracted to complexity.

There are times when I use command lines, with OS X or Windows systems. There are times when I use GUI tools. I don't care, as long as I limit the chances to get in a worse situation than the one I started with.

You seem to enjoy the intellectual puzzle to solve, with little or no consideration to the consequences of the advice you are giving, and enjoying on the way putting down anyone who doesn't think like you or suggests non hyper-technical solutions (i.e. solutions not relying on you guiding the user step by step because they have no idea what they are doing).

I used to work as a developper, I have maintained hundreds of systems over the years, but the more I deal with computers, the more humble I become, and the less I believe I know what the outcome of ANY command or procedure is going to be. Simply because it never, ever goes how it should, however simple or complex the task is supposed to be. Well sometimes it does, but I see it as luck, not as the result of competence or knowledge.

Which you are going to immediately translate as I'm ignorant and incompetent.

Over and out, for good this time. Promise🙂.

@McManni

It's hilarious to read your hysterical assertions of hypothetical damage to user data by editing partitions with tools that cannot do what you claim; and yet are tools that Disk Utility and Boot Camp Assistant themselves leverage. While at the same time your prescription is to actually destroy original user data, by repartitioning and reformatting the drive containing original data, and restoring from a single backup.

My method retains original user data plus a copy. Your method depends on one copy. It's inherently more risky.

You further lecture me on ignoring the possibility of user data damage, while you ignore the possibility of backup/restore failure. Significant available data on the subject of, and user annecdotes, on backup-restore procedures, demonstrates that backup and/or restore failure is actually pretty common. But for some reason you promote the outlandish improbable user data damage (with no theoretical or practical explanation as to how this would occur).

Mind you the author of Winclone expressly states that it's not making a backup.

Further, you blantly propose that computers are not deterministic machines, as if they can do things they were not expressly coded for. I can directly attest that your position is not taught in computer science.

This fixed the issue for me.

1) Backup the Bootcamp partition using Winclone

2) Backup Mac OSX drive using Carbon Copy Clone to an external drive

3) Install Mountain Lion to a flash drive or external drive

4) Purchase a copy of iPartition, download to flash drive or external drive

5) Reboot while holding the Option key to get boot menu

6) Select the flash or external drive to boot from

7) Extract iPartition and execute. Select View and Inspector from the dropdown menu.

8) Select Bootcamp Partition under the Partition tab and check off the two boxes in the list (Active and Visible in Windows) then close the box.

9) The Go button should be illuminated, if not then grow the Bootcamp partition a little. Mine is 2 TB OSX, 500 GB Windows on a 2.5 TB Drive.

10) Once the Go button is pressed it should start to process; although you may have to kill any process that keeps it from running (Done with Activity Monitor)

11) Once finished shut down and remove the external boot device and then power the Mac back on. It should be fixed and boot normal -- at least mine did.

I'm running an iMac 27, 3.2 GHz Intel Core i3 with 16 GB RAM and a 2.5 TB hard drive. Most of the items listed I had already done prior to Mountain Lion install except for a current backup of the Bootcamp drive. Winclone worked even though Bootcamp wouldn't boot and the restore process generated an error writing the MBR. I just ignored the error and continued onward with the rest of the process. Apparently Mountain Lion messed with the PMBR or the EFI and even rEFIt wouldn't fix it but whatever iPartition did; its now fixed.

*****DISCLAIMER****

While this process may have worked fine for me IT MAY NOT WORK FOR YOU! AS WITH ANY PROCESS THAT EDITS THE PARTITON TABLE AND BOOT DATA, YOU STAND A CHANCE OF LOSING DATA. BACKUP YOUR DRIVE IF YOU WANT TO KEEP YOUR DATA.

I highly recommend Carbon Copy Clone for backing up the OSX partition because it can create a bootable clone that I've never had fail.

I'm sure others have had success elsewhere in resolving this issue and appreciate everyone who has posted what they have done as it helped me resolve this issue on my iMac.

Thanks to everyone and I hope this helps someone.

This is rather mysterious, how you're getting this to work on a > 2TB disk, when MBR cannot support disks of that size. Do you mind posting the results of some read-only commands that do not modify any information on the disk?

diskutil info /dev/disk0

sudo gpt -r -vv show disk0

sudo fdisk /dev/disk0

Sure, here ya go.

Oh and I'm running Windows 7 Ultimate 64 Bit in the Bootcamp partiton.

iMac:~ root# diskutil info /dev/disk0

Device Identifier: disk0

Device Node: /dev/disk0

Part of Whole: disk0

Device / Media Name: WDC WD25EZRX-00MMMB0 Media

Volume Name: Not applicable (no file system)

Mounted: Not applicable (no file system)

File System: None

Content (IOContent): GUID_partition_scheme

OS Can Be Installed: No

Media Type: Generic

Protocol: SATA

SMART Status: Verified

Total Size: 2.5 TB (2500495958016 Bytes) (exactly 4883781168 512-Byte-Blocks)

Volume Free Space: Not applicable (no file system)

Device Block Size: 512 Bytes

Read-Only Media: No

Read-Only Volume: Not applicable (no file system)

Ejectable: No

Whole: Yes

Internal: Yes

Solid State: No

OS 9 Drivers: No

Low Level Format: Not supported

iMac:~ root# gpt -r -vv show disk0

gpt show: disk0: mediasize=2500495958016; sectorsize=512; blocks=4883781168

gpt show: disk0: Suspicious MBR at sector 0

gpt show: disk0: Pri GPT at sector 1

gpt show: disk0: Sec GPT at sector 4883781167

start size index contents

0 1 MBR

1 1 Pri GPT header

2 32 Pri GPT table

34 6

40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B

409640 3881187072 3 GPT part - 48465300-0000-11AA-AA11-00306543ECAC

3881596712 1269544 4 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

3882866256 432

3882866688 1000912896 2 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

4883779584 1551

4883781135 32 Sec GPT table

4883781167 1 Sec GPT header

iMac:~ root# fdisk /dev/disk0

Disk: /dev/disk0 geometry: 36651/255/63 [588813872 sectors]

Signature: 0xAA55

Starting Ending

#: id cyl hd sec - cyl hd sec [ start - size]

------------------------------------------------------------------------

1: EE 0 0 2 - 1023 254 63 [ 1 - -412100609] <Unknown ID>

*2: 07 1023 254 63 - 1023 254 63 [-412100608 - 1000912896] HPFS/QNX/AUX

3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

iMac:~ root#