You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Bootcamp partition has disappeared after upgrade to Yosemite 10.10

Hello Loner T,


I've been following the threads of people with similar issues for the last couple of days now. I downloaded Testdisk and GPT disk both. And I've been trying to follow the directions as best I could on my own to see if I could re-set/re-write the GPT and MBR entries. My situation is a little different from the others in that I manually opened my iMac and installed an SSD which populates /dev/disk1(for recovery volume) and /disk2/ which is my boot drive. /dev/disk0 the internal 1TB drive became extra storage and location for the Bootcamp partition. So following these directions initially to pin down where on Disk0 things were located I narrowed it down to /dev/disk0s3

  1. diskutil list
  2. diskutil cs list (to find if Core Storage is the culprit)
  3. Download GPT Disk from sourceforge.org and install it.
  4. sudo gpt -vv -r show /dev/disk0
  5. sudo fdisk /dev/disk0

Here's the output from each of the steps, the beginning of the tests----------------------------------------------------------

User uploaded file

User uploaded file

User uploaded file

User uploaded file

-------------------------------------------------------------------------------- -End of Tests-----------------------------------------------------

So /dev/disk0s3 is the location. But I'm having real difficulties now getting further as I tried this command just to see if I could find the 'R.NTFS' entry in the hexdump from the dd command:

sudo dd if=/dev/rdisk0s3 count=1 2>/dev/null | hexdump -C

Ambiguous output redirect

Do I have that commandline correct?

Also I've done a full run of Test disk in Quick Search and Deep Search that I can post if needed. I'm finding it's very odd compared to what I've seen other people posting so far. I've got 2 complete Windows partitions with what looks to be the same files in both locations. I did extend the volume at one point to boost it up to 250GB. Don't know if that's causing the GPT/MBR to show a total of 8 entries in Testdisk. But that's what I'm seeing when I run it. Will await any further steps or directions you might have. I'm hoping this is quick fix. But I'm willing to do a full GPT re-wrtie/reset and an MBR rebuild if necessary and of course the Windows Recovery if it comes to that. I cannot thank you enough for being so generous with your knowledge and expertise, it's been a real education in the low level vagaries of disk management on the Mac for the past 2-3 days.

OS X Yosemite (10.10)

Posted on Nov 15, 2014 6:22 AM

Reply
43 replies

Nov 15, 2014 1:30 PM in response to Loner T

No it doesn't prompt me for some reason, it just errors out on the syntax, same response: Ambiguous output redirect.


I've tried also a step-by-step approach typing in partial bits of the commandline just now. It asks for the sudo password up until the pipe. It hates that pipe for some reason. I don't know if this is some result of a .cshrc or other customization I may have done in the past. I think I can pipe outputs to inputs generally. So I'll see if I can narrow this down some more. I just did a quick test of ls | grep in a directory. That seemed to work piping works generally, why I cannot pipe the output from dd into hexdump is a mystery.

Nov 15, 2014 2:12 PM in response to elikness

I figured out the error. It was my default shell /bin/tcsh that was shooting me in the foot.
I forced a chsh to /bin/bash and now I finally got this result.
And I note I don't see the name "R.NTFS" in the hexdump output:


bash-3.2$ sudo dd if=/dev/rdisk0s3 count=1 2>/dev/null | hexdump -C

00000000 46 49 4c 45 30 00 03 00 67 bb 09 21 05 00 00 00 |FILE0...g..!....|

00000010 0e 00 02 00 38 00 03 00 d0 02 00 00 00 04 00 00 |....8...........|

00000020 00 00 00 00 00 00 00 00 04 00 00 00 c8 ec 01 00 |................|

00000030 05 00 35 00 00 00 00 00 10 00 00 00 60 00 00 00 |..5.........`...|

00000040 00 00 00 00 00 00 00 00 48 00 00 00 18 00 00 00 |........H.......|

00000050 53 47 f3 f9 4b 9f ce 01 53 47 f3 f9 4b 9f ce 01 |SG..K...SG..K...|

00000060 b9 1d 26 7b 87 51 cf 01 53 47 f3 f9 4b 9f ce 01 |..&{.Q..SG..K...|

00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000080 00 00 00 00 8f 0a 00 00 00 00 00 00 00 00 00 00 |................|

00000090 18 7f e9 84 01 00 00 00 30 00 00 00 78 00 00 00 |........0...x...|

000000a0 00 00 00 00 00 00 03 00 5a 00 00 00 18 00 01 00 |........Z.......|

000000b0 ed bb 01 00 00 00 16 00 5f 0c 09 6d 86 51 cf 01 |........_..m.Q..|

000000c0 5f 0c 09 6d 86 51 cf 01 5f 0c 09 6d 86 51 cf 01 |_..m.Q.._..m.Q..|

000000d0 5f 0c 09 6d 86 51 cf 01 00 00 00 00 00 00 00 00 |_..m.Q..........|

000000e0 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 |................|

000000f0 0c 02 58 00 38 00 44 00 38 00 42 00 38 00 7e 00 |..X.8.D.8.B.8.~.|

00000100 31 00 2e 00 31 00 36 00 33 00 74 00 2d 00 77 00 |1...1.6.3.t.-.w.|

00000110 30 00 00 00 00 01 00 00 00 00 00 00 00 00 02 00 |0...............|

00000120 e8 00 00 00 18 00 01 00 ed bb 01 00 00 00 16 00 |................|

00000130 5f 0c 09 6d 86 51 cf 01 5f 0c 09 6d 86 51 cf 01 |_..m.Q.._..m.Q..|

*

00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000160 00 00 00 10 00 00 00 00 53 01 78 00 38 00 36 00 |........S.x.8.6.|

00000170 5f 00 6d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 |_.m.i.c.r.o.s.o.|

00000180 66 00 74 00 2d 00 77 00 69 00 6e 00 64 00 6f 00 |f.t.-.w.i.n.d.o.|

00000190 77 00 73 00 2d 00 72 00 65 00 63 00 6f 00 76 00 |w.s.-.r.e.c.o.v.|

000001a0 65 00 72 00 5f 00 33 00 31 00 62 00 66 00 33 00 |e.r._.3.1.b.f.3.|

000001b0 38 00 35 00 36 00 61 00 64 00 33 00 36 00 34 00 |8.5.6.a.d.3.6.4.|

000001c0 65 00 33 00 35 00 5f 00 36 00 2e 00 33 00 2e 00 |e.3.5._.6...3...|

000001d0 39 00 36 00 30 00 30 00 2e 00 31 00 36 00 33 00 |9.6.0.0...1.6.3.|

000001e0 38 00 34 00 5f 00 6e 00 6f 00 6e 00 65 00 5f 00 |8.4._.n.o.n.e._.|

000001f0 31 00 61 00 62 00 33 00 31 00 32 00 35 00 05 00 |1.a.b.3.1.2.5...|

00000200

Nov 15, 2014 2:38 PM in response to Loner T

I'm now running TestDisk (Quick Search) on /dev/rdisk0. And this is what I get:

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

Disk /dev/rdisk0 - 1000 GB / 931 GiB - 1953525168 sectors (RO)

Current partition structure:

Partition Start End Size in sectors


1 P EFI System 40 409639 409600 [EFI System Partitio

2 P Mac HFS 409640 1465253383 1464843744 [Customer]

No FAT, NTFS, ext2, JFS, Reiser, cramfs or XFS marker

3 P MS Data 1713563648 1953523711 239960064 [BOOTCAMP]

3 P MS Data 1713563648 1953523711 239960064 [BOOTCAMP]

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

There's two entries for MS Data with the same exact number for each one.

Also I have another window open running TestDisk Deep Search on the /dev/rdisk0, just to keep things rolling along. It's not quite 1/2 done. Will report the results of Deep Search as well.

Nov 15, 2014 3:50 PM in response to elikness

I've run the TestDisk a second time on the /dev/disks3 and got this result too:


The harddisk (1000 GB / 931 GiB) seems too small! (< 1250 GB / 1164 GiB)

Check the harddisk size: HD jumpers settings, BIOS detection...


The following partitions can't be recovered:

Partition Start End Size in sectors

Mac HFS 1953292932 1961681541 8388610 [~?~?~?M-:D^A]

> MS Data 1953523704 2441793520 488269817

MS Data 1953523711 2441793527 488269817

Mac HFS 1953525124 1954794659 1269536

The start for the first MS Data part is different from the second one. the total size is the same though. Still running Deep Search right now.

Nov 16, 2014 5:55 AM in response to Loner T

Ran Testdisk Deeper Search and got t his result:

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

Disk /dev/rdisk0 - 1000 GB / 931 GiB - 1953525168 sectors (RO)


The harddisk (1000 GB / 931 GiB) seems too small! (< 1900 GB / 1770 GiB)

Check the harddisk size: HD jumpers settings, BIOS detection...


The following partitions can't be recovered:

Partition Start End Size in sectors

> Mac HFS 1465253380 2930097123 1464843744

MS Data 1484632928 1972902744 488269817

MS Data 1552796436 2041189139 488392704

MS Data 1552949657 2041342360 488392704

MS Data 1562223539 2050616242 488392704

MS Data 1566953729 2055346432 488392704

MS Data 1708964480 2196312703 487348224

MS Data 1709136672 2196484895 487348224

MS Data 1711042112 2198390335 487348224

MS Data 1714782560 2202130783 487348224

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

There's a total of 9 parts.

Which one should I pick? Should I pick the Lowest and Highest numbers? I don't know where the "R.NTFS" file is or where to find it from this Deeper Search result.

Also on further inspection I drilled down into the part listing and found this bit of extra info:

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

D Mac HFS 52367852 52467851 100000

D Mac HFS 52367925 52467924 100000

D Mac HFS 52367974 52467973 100000

D Mac HFS 52368007 52468006 100000

D Mac HFS 52467284 52567283 100000

D Mac HFS 89712220 1900963421 1811251202 [D]

D MS Data 449208984 449211863 2880 [EFISECTOR]

D MS Data 449222131 449228304 6174

>D MS Data 449228304 449234477 6174 [Boot]

D MS Data 457053176 457056055 2880 [EFISECTOR]

D MS Data 457056056 457058935 2880 [EFISECTOR]

D MS Data 509565060 997957763 488392704

D MS Data 537080580 1025473283 488392704

D MS Data 541603296 1029995999 488392704

D MS Data 578968160 1067360863 488392704

D MS Data 797413281 965179296 167766016

D MS Data 857706980 1025472995 167766016

D MS Data 920727428 961683331 40955904

D MS Data 945969469 1029851452 83881984

D MS Data 946116960 1029998943 83881984

D MS Data 961683331 1002639234 40955904

D MS Data 965179296 1132945311 167766016

D MS Data 977905665 1465253888 487348224

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

Looks like the section marked [Boot] has a file in it named System Volume Information. So would that be the beginning of the partition? or would be one of the entries precedingthatat one in the list? For example the very first one marked MS Data with start 449208984/449211863 size:2880 [EFISECTOR]

Nov 16, 2014 6:11 AM in response to Loner T

Also just did a line by line search attempting to find Windows files using Print to search all the entries. Found and discovered this entry had the windows files in it:

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

MS Data 1465253888 1952602111 487348224

Directory /


>dr-xr-xr-x 0 0 0 15-Oct-2014 20:18 .

dr-xr-xr-x 0 0 0 15-Oct-2014 20:18 ..

dr-xr-xr-x 0 0 0 12-May-2014 22:52 $Recycle.Bin

dr-xr-xr-x 0 0 0 5-Apr-2014 22:19 AMD

dr-xr-xr-x 0 0 0 10-Oct-2014 23:36 Boot

dr-xr-xr-x 0 0 0 15-Oct-2014 20:19 Config.Msi

dr-xr-xr-x 0 0 0 22-May-2013 18:49 DeploymentShare

dr-xr-xr-x 0 0 0 22-Feb-2012 00:02 Intel

dr-xr-xr-x 0 0 0 31-May-2013 22:04 MSOCache

dr-xr-xr-x 0 0 0 22-Aug-2013 11:22 PerfLogs

dr-xr-xr-x 0 0 0 5-Jun-2014 18:08 Program Files

dr-xr-xr-x 0 0 0 19-Jul-2014 10:34 Program Files (x86)

dr-xr-xr-x 0 0 0 5-Jun-2014 18:10 ProgramData

dr-xr-xr-x 0 0 0 6-Apr-2014 07:02 Recovery

dr-xr-xr-x 0 0 0 15-Oct-2014 23:21 System Volume Information

dr-xr-xr-x 0 0 0 6-Apr-2014 22:51 Users

dr-xr-xr-x 0 0 0 3-Jul-2013 23:18 VHDs

dr-xr-xr-x 0 0 0 6-Apr-2014 23:36 WIMs

dr-xr-xr-x 0 0 0 6-Oct-2014 22:55 Windows

dr-xr-xr-x 0 0 0 21-Apr-2013 18:45 winpe4_amd64

dr-xr-xr-x 0 0 0 21-Apr-2013 18:11 winpe4_x86

-r--r--r-- 0 0 1 18-Jun-2013 08:18 BOOTNXT

-r--r--r-- 0 0 8192 5-Apr-2014 22:51 BOOTSECT.BAK

-r--r--r-- 0 0 2066 6-Apr-2014 06:35 RHDSetup.log

-r--r--r-- 0 0 404250 14-Jun-2014 06:46 bootmgr

-r--r--r-- 0 0 27467431936 14-Oct-2014 23:08 hiberfil.sys

-r--r--r-- 0 0 5100273664 14-Oct-2014 23:09 pagefile.sys

-r--r--r-- 0 0 268435456 14-Oct-2014 23:09 swapfile.sys

-r--r--r-- 0 0 409256444 24-Dec-2012 19:49 winpe_x86.zip

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

This one also has the windows files in it. So the question is which one is the right one? Looks like the sizes and End points vary a little.

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

MS Data 1465253888 1953523704 488269817

Directory /


>dr-xr-xr-x 0 0 0 15-Oct-2014 20:18 .

dr-xr-xr-x 0 0 0 15-Oct-2014 20:18 ..

dr-xr-xr-x 0 0 0 12-May-2014 22:52 $Recycle.Bin

dr-xr-xr-x 0 0 0 5-Apr-2014 22:19 AMD

dr-xr-xr-x 0 0 0 10-Oct-2014 23:36 Boot

dr-xr-xr-x 0 0 0 15-Oct-2014 20:19 Config.Msi

dr-xr-xr-x 0 0 0 22-May-2013 18:49 DeploymentShare

dr-xr-xr-x 0 0 0 22-Feb-2012 00:02 Intel

dr-xr-xr-x 0 0 0 31-May-2013 22:04 MSOCache

dr-xr-xr-x 0 0 0 22-Aug-2013 11:22 PerfLogs

dr-xr-xr-x 0 0 0 5-Jun-2014 18:08 Program Files

dr-xr-xr-x 0 0 0 19-Jul-2014 10:34 Program Files (x86)

dr-xr-xr-x 0 0 0 5-Jun-2014 18:10 ProgramData

dr-xr-xr-x 0 0 0 6-Apr-2014 07:02 Recovery

dr-xr-xr-x 0 0 0 15-Oct-2014 23:21 System Volume Information

dr-xr-xr-x 0 0 0 6-Apr-2014 22:51 Users

dr-xr-xr-x 0 0 0 3-Jul-2013 23:18 VHDs

dr-xr-xr-x 0 0 0 6-Apr-2014 23:36 WIMs

dr-xr-xr-x 0 0 0 6-Oct-2014 22:55 Windows

dr-xr-xr-x 0 0 0 21-Apr-2013 18:45 winpe4_amd64

dr-xr-xr-x 0 0 0 21-Apr-2013 18:11 winpe4_x86

-r--r--r-- 0 0 1 18-Jun-2013 08:18 BOOTNXT

-r--r--r-- 0 0 8192 5-Apr-2014 22:51 BOOTSECT.BAK

-r--r--r-- 0 0 2066 6-Apr-2014 06:35 RHDSetup.log

-r--r--r-- 0 0 404250 14-Jun-2014 06:46 bootmgr

-r--r--r-- 0 0 27467431936 14-Oct-2014 23:08 hiberfil.sys

-r--r--r-- 0 0 5100273664 14-Oct-2014 23:09 pagefile.sys

-r--r--r-- 0 0 268435456 14-Oct-2014 23:09 swapfile.sys

-r--r--r-- 0 0 409256444 24-Dec-2012 19:49 winpe_x86.zip

Nov 16, 2014 6:41 AM in response to elikness

MS Data 1465253888 1952602111 487348224

MS Data 1465253888 1953523704 488269817

Both of these start at the same offset so they look like the same partition, hence the content looks the same.

If you look at the gap between GPT#3 and #4 which starts at 1465253384 (your two entries are 4 bytes further higher), this looks to be the best available candidate. I suggest using the second entry since it is larger in size.

You need to delete GPT#4 and recreate it with the second entry which start/end/size triplet. If you need the steps, post back and I can cut/paste from a different thread.

Nov 16, 2014 8:18 AM in response to Loner T

Just to make sure, you want me to delete #4 and not #3? I thought #3 was the affected/damaged slice.


I think I can do delete/recreate based on all the other people you've helped. I'll give it a shot. And since it's not my boot drive I feel pretty safe editing the GPT.

Also, do I need to rebuild/reset the MBR to match the GPT once I've edited it?

I'll let you know how it goes.Thanks for the consult/advice.

Nov 16, 2014 10:24 AM in response to Loner T

That would be the case if /dev/disk0 was my boot drive. But I manually installed an SSD which I assigned as my boot drive and now /dev/disk1 is the drive that contains my Recovery Drive. /dev/disk0 is a spare data drive that I used to install Bootcamp and keep extra files on within Mac OS X. This is the screen shot from the command showing the devices and their slices. As you can see /dev/disk1 has GPT#3 as its Recovery HD, where as /dev/disk0 is the drive with Bootcamp.


It's a non-standard layout, but I'm going to guess that /dev/disk0s3 (GPT#3) is the slice that needs to be manipulated and replaced?

User uploaded file

Bootcamp partition has disappeared after upgrade to Yosemite 10.10

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.