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

Level 1

17 points

Bootcamp booting clobbered by Yosemite upgrade

I've enjoyed being able to boot into OSX Mavericks or Windows 8.1 for the past year on my MBP (mid 2012, single 500GB SSD) but I recently performed the Yosemite upgrade. The resulting OSX installation appears to work fine but when I hold down the Option key after the chime the option to boot from Bootcamp Windows is missing. Worse, when I set "Startup Disk" to Bootcamp Windows the result fails.

@Loner T usually requests the following Terminal results so here they are:

Last login: Sun Sep 20 22:09:22 on ttys000

My-MacBook-Pro:~ me$ diskutil list

/dev/disk0

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *512.1 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_CoreStorage 255.3 GB disk0s2

3: Apple_Boot Recovery HD 650.0 MB disk0s3

4: Microsoft Basic Data BOOTCAMP 255.5 GB disk0s4

/dev/disk1

#: TYPE NAME SIZE IDENTIFIER

0: Apple_HFS Macintosh HD *254.9 GB disk1

Logical Volume on disk0s2

F6545BAB-5B31-4838-A188-C59D210B12FB

Unencrypted

==========

My-MacBook-Pro:~ me$ diskutil cs list

CoreStorage logical volume groups (1 found)

+-- Logical Volume Group B8FA8874-F8C3-4EC1-8F53-0F555EDFC166

=========================================================

Name: Macintosh HD

Status: Online

Size: 255250432000 B (255.3 GB)

Free Space: 18907136 B (18.9 MB)

+-< Physical Volume 84E5E470-49E8-4585-AA1D-397BDEA61A3D

| ----------------------------------------------------

| Index: 0

| Disk: disk0s2

| Status: Online

| Size: 255250432000 B (255.3 GB)

+-> Logical Volume Family E409753F-A5B6-4DAC-BF6F-17CE4956E11E

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

Encryption Status: Unlocked

Encryption Type: None

Conversion Status: NoConversion

Conversion Direction: -none-

Has Encrypted Extents: No

Fully Secure: No

Passphrase Required: No

+-> Logical Volume F6545BAB-5B31-4838-A188-C59D210B12FB

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

Disk: disk1

Status: Online

Size (Total): 254879203328 B (254.9 GB)

Conversion Progress: -none-

Revertible: Yes (no decryption required)

LV Name: Macintosh HD

Volume Name: Macintosh HD

Content Hint: Apple_HFS

==========

My-MacBook-Pro:~ me$ sudo gpt -vv -r show /dev/disk0

Password:

gpt show: /dev/disk0: mediasize=512110190592; sectorsize=512; blocks=1000215216

gpt show: /dev/disk0: PMBR at sector 0

gpt show: /dev/disk0: Pri GPT at sector 1

gpt show: /dev/disk0: Sec GPT at sector 1000215215

start size index contents

0 1 PMBR

1 1 Pri GPT header

2 32 Pri GPT table

34 6

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

409640 498536000 2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC

498945640 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

500215176 632

500215808 499077120 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

999292928 922255

1000215183 32 Sec GPT table

1000215215 1 Sec GPT header

==========

My-MacBook-Pro:~ me$ sudo fdisk /dev/disk0

Disk: /dev/disk0 geometry: 62260/255/63 [1000215216 sectors]

Signature: 0xAA55

Starting Ending

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

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

1: EE 1023 254 63 - 1023 254 63 [ 1 - 1000215215] <Unknown ID>

2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

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

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

I would appreciate help getting Bootcamp booting again.

Posted on Sep 20, 2015 8:43 PM

68 replies

trwd Author

Level 1

17 points

Sep 30, 2015 5:53 PM in response to Loner T

I understand that TB IFL's exact copy did not put the GPT secondary 32 sectors from the physical end of last sector, but wasn't that fixed when I changed the GUID and agreed to let this problem be fixed?

So at this point would you agree that the HDD copy is as compatible with the MBP as the original, up to spec, ready to use -- provided it's the only boot drive connected (i.e., the original drive is no longer connected)?

I'd like to close this much of the case if possible.

trwd Author

Level 1

17 points

Sep 30, 2015 5:55 PM in response to Loner T

From the following segment of your reply:

The GUID and the entire connection path are used. There is also boot ability in play here. There is a 'bless' command, which allows EFI and/or MBR (in legacy mode) partitions on how booting is accomplished. With CoreStorage in place, you will have metadata and journaling conflicts which are used for recovery purposes in CS settings. JHFS+ is much simpler, and once you change the disk GUIDs, the journals and identity are unique.

I gather that the answer to my "threshold question":

Was I wrong believing that the identical GUID's was the obstacle to keeping both drives connected?

.. is: Yes, you (OP) were wrong; other factors related to both drives using CoreStorage are an obstacle to using an original drive and its clone connected at the same time.

Do you agree with the above?

Loner T

Level 9

59,477 points

Sep 30, 2015 5:55 PM in response to trwd

trwd wrote:

I understand that TB IFL's exact copy did not put the GPT secondary 32 sectors from the physical end of last sector, but wasn't that fixed when I changed the GUID and agreed to let this problem be fixed?

It is expected behavior and expected result. Gdisk should have corrected it as long as we did the write and reboot. You can also check it on the destination with the GPT command.

So at this point would you agree that the HDD copy is as compatible with the MBP as the original, up to spec, ready to use -- provided it's the only boot drive?

It would be good to address this as well. One test I would suggest is using a 16Gb Flash disk with the HDD connected, booting from the Recovery HD on the HDD (using Al/Option key), and installing OS X on the 16GB USB and booting from it to ensure external disks do not see any other issues.

I'd like to close this much of the case if possible.

Certainly. Can you also test backing up the OS X and Windows partitions? It will help in ensuring recoverability of both OSes without any further issues. Time Machine uses the disk GUIDs of what is being backed up and the partition information as well as Recovery HD. We should ensure reliability for any future use. You do not want any underlying issues to come back later and cause more problems.

Loner T

Level 9

59,477 points

Sep 30, 2015 5:58 PM in response to trwd

trwd wrote:

From the following segment of your reply:

The GUID and the entire connection path are used. There is also boot ability in play here. There is a 'bless' command, which allows EFI and/or MBR (in legacy mode) partitions on how booting is accomplished. With CoreStorage in place, you will have metadata and journaling conflicts which are used for recovery purposes in CS settings. JHFS+ is much simpler, and once you change the disk GUIDs, the journals and identity are unique.

I gather that the answer to my "threshold question":

Was I wrong believing that the identical GUID's was the obstacle to keeping both drives connected?

.. is: Yes, you (OP) were wrong; other factors related to both drives using CoreStorage are an obstacle to using an original drive and its clone connected at the same time.

Do you agree with the above?

No, you are not wrong. There are additional parameters to the equation, this being one. Do not short-change yourself. 😉

trwd Author

Level 1

17 points

Sep 30, 2015 7:07 PM in response to Loner T

Ah, well played Loner T! 😎

I believe I already checked the copy HDD's Secondary GPT earlier this morning and posted the result:

sudo gpt -vv -r show /dev/disk2

gpt show: /dev/disk2: mediasize=1500301910016; sectorsize=512; blocks=2930277168

gpt show: /dev/disk2: PMBR at sector 0

gpt show: /dev/disk2: Pri GPT at sector 1

gpt show: /dev/disk2: Sec GPT at sector 2930277167

start size index contents

0 1 PMBR

1 1 Pri GPT header

2 32 Pri GPT table

34 6

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

409640 498536000 2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC

498945640 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

500215176 632

500215808 499077120 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

999292928 1930984207

2930277135 32 Sec GPT table

2930277167 1 Sec GPT header

Based on the tests you propose I take it we are not ready to declare the current HDD copy a 100% successful clone.

Tests you propose (with details needed):

1. Make a 16GB flash drive:

disconnect the internal SSD
power up the MBP with Command + R pressed (besides listening for a lot of head movement in the HDD, how will I know if the recovery environment on the HDD is being used instead of from the Internet? Disconnect the network cable?)
install OS X on the 16GB flash drive (can you point me to a link that explains your preferred method?)
"ensure external disks do not see any other issues" (how do I do that?) At this point I'll have two USB drives (the HDD and the 16GB flash) connected. Is that a valid way to do this? Is the purpose of the 16GB drive to test having two CS drives connected simultaneously, booting from either?

2. Test backing up the OS X and Windows partitions:

If Time Machine was already configured for the old system won't the new randomly set GUID on the copy HDD throw it off track?
By "backing up the Windows partition" are you referring to trying a program like WinClone or what? Remember: my Windows partition exists but is not bootable yet.

This thread has evolved into two goals: the original need to make Bootcamp boot again, and the now almost more compelling goal of determining a way to successfully clone a dual-boot Mac with the fewest steps possible. I think Mac Bootcamp users would love to have a slam-dunk method to clone their systems, for backup and for migration to a new drive. Using Terabyte's Image for Linux is familiar territory for Windows users because it involves booting from a flash drive and copying one drive to another. Except for the "possibility" that Clonezilla can clone a dual-boot Mac drive (I could find no proof or precise recipe), IFL may be the only solution available.

You appear to be encouraging me to stop, go back and disable CoreStorage, and then make a copy using IFL (an approach the Terabyte guy likes because the copying process will be much faster). The idea of modifying my original drive like that worries me because I figure Apple implemented CS for a good reason. Are you suggesting this change of direction because you think I might be able to have the original SSD and the copy HDD connected at the same time -- either bootable, unlike my current problem where they seem to conflict? Can you explain in layman terms the implications and possible repercussions of disabling CoreStorage?

Loner T

Level 9

59,477 points

Sep 30, 2015 7:45 PM in response to trwd

trwd wrote:

I believe I already checked the copy HDD's Secondary GPT earlier this morning and posted the result...

Which also adds to the fact that the Gdisk did correct the GPT and pushed it to the correct place.

Based on the tests you propose I take it we are not ready to declare the current HDD copy a 100% successful clone.

Tests you propose (with details needed):

1. Make a 16GB flash drive:

disconnect the internal SSD

power up the MBP with Command + R pressed (besides listening for a lot of head movement in the HDD, how will I know if the recovery environment on the HDD is being used instead of from the Internet? Disconnect the network cable?)

install OS X on the 16GB flash drive (can you point me to a link that explains your preferred method?)

"ensure external disks do not see any other issues" (how do I do that?) At this point I'll have two USB drives (the HDD and the 16GB flash) connected. Is that a valid way to do this? Is the purpose of the 16GB drive to test having two CS drives connected simultaneously, booting from either?

You can leave the ethernet cable connected. If you see a spinning globe before it shows you the console, it is not using local recovery. This will indicate if the Recovery HD is valid or not. You can use How to install OS X on an external drive connected to your Mac - Apple Support to put OS X on an external disk. Once you have a bootable USB, connect both the HDD and SSD to the SATA bus, but still boot from the USB. The USB will not be CS, but the HDD and SSD will be.

2. Test backing up the OS X and Windows partitions:

If Time Machine was already configured for the old system won't the new randomly set GUID on the copy HDD throw it off track?

By "backing up the Windows partition" are you referring to trying a program like WinClone or what? Remember: my Windows partition exists but is not bootable yet.

The purpose of this test is to ensure that the Time Machine UI (the Star Wars display) will let you see the older SSD volumes and the newer HDD, both. This will allow you to recover your Mac from either the pre-HDD state or post-HDD state. Time Machine is expected to handle a hardware failure and manage a drive replacement seamlessly without the user having to think too hard about it.

If the clone is true, Bootcamp's MBR (Hybrid MBR) should also be available and allow boot ability. Windows licensing is problematic and any hardware change invalidates the already activated Product Key. We need to address this as well. You may need Windows Startup Repair.

This thread has evolved into two goals: the original need to make Bootcamp boot again, and the now almost more compelling goal of determining a way to successfully clone a dual-boot Mac with the fewest steps possible. I think Mac Bootcamp users would love to have a slam-dunk method to clone their systems, for backup and for migration to a new drive. Using Terabyte's Image for Linux is familiar territory for Windows users because it involves booting from a flash drive and copying one drive to another. Except for the "possibility" that Clonezilla can clone a dual-boot Mac drive (I could find no proof or precise recipe), IFL may be the only solution available.

You appear to be encouraging me to stop, go back and disable CoreStorage, and then make a copy using IFL (an approach the Terabyte guy likes because the copying process will be much faster). The idea of modifying my original drive like that worries me because I figure Apple implemented CS for a good reason. Are you suggesting this change of direction because you think I might be able to have the original SSD and the copy HDD connected at the same time -- either bootable, unlike my current problem where they seem to conflict? Can you explain in layman terms the implications and possible repercussions of disabling CoreStorage?

There is a much simpler test that you can perform, without touching the original SSD. Connect your HDD, boot from the external USB Flash drive (warning - this is very slow). Run diskutil cs revert on the HDD only. Now try and connect both SSD and HDD to SATA bus and test booting from all three.

trwd Author

Level 1

17 points

Sep 30, 2015 9:21 PM in response to Loner T

Wonderfully helpful reply. Thank you.

Perhaps the following is important to recognize before I proceed: the current HDD copy I'm working with is a 3.5" SATA HDD plugged into a USB 3 Dock. All the tests I've done thus far involved using it while connected to the MBP's USB 3 port. From your recent reply it sounds like you want me to connect this drive to the SATA port in the MBP, which I obviously cannot do. I may have a 2.5" HDD here that I can switch to but please confirm whether I need to be using the "destination drive" on a SATA port for any of these tests.

----

Also, you wrote: " Once you have a bootable USB, connect both the HDD and SSD to the SATA bus, but still boot from the USB. The USB will not be CS, but the HDD and SSD will be.." Are you referring only to the 16GB flash drive OS X installation from the recovery console not being CS?

------

Your last paragraph said: "There is a much simpler test that you can perform, without touching the original SSD. Connect your HDD (to the SATA port or to the other USB port?), boot from the external USB Flash drive (warning - this is very slow). Run diskutil cs revert on the HDD only. Now try and connect both SSD and HDD to SATA bus (wha?! If the SSD is connected it'll be using the internal SATA port. Unless I use the optical drive's SATA port there isn't a SATA port available for the HDD copy) and test booting from all three."

I certainly like the idea of not modifying my SSD so thank you very much for coming up with an alternate plan. See my questions in italics within the above quote.

----

Since your new proposed plan does not include disabling CS on the original SSD, and then making a copy of it, it sounds to me like we're just trying to disable CS in one of the two otherwise identical drives (noting the GUID difference, too). If you believe that both drives using CS is the cause of my current inability to have both the HDD and the SSD connected simultaneously and Option-key boot from either, why don't I:

boot from the SSD
connect the HDD via USB after the MBP has booted
disable CS on the HDD from Terminal
shutdown
power up, hold down Option key, and try booting from the HDD

The CS SSD will be SATA. The JHFS+ HDD will be USB. Is it worth a try? We're using the HDD for two things: to test the integrity of a TB IFL clone and to test a few methods for fixing my Yosemite-upgrade-clobbered-Bootcamp capability. I'm not going to use the HDD beyond that so I don't care about disabling CS on it -- unless it invalidates any of these tests.

Loner T

Level 9

59,477 points

Oct 1, 2015 4:10 AM in response to trwd

trwd wrote:

Wonderfully helpful reply. Thank you.

Perhaps the following is important to recognize before I proceed: the current HDD copy I'm working with is a 3.5" SATA HDD plugged into a USB 3 Dock. All the tests I've done thus far involved using it while connected to the MBP's USB 3 port. From your recent reply it sounds like you want me to connect this drive to the SATA port in the MBP, which I obviously cannot do. I may have a 2.5" HDD here that I can switch to but please confirm whether I need to be using the "destination drive" on a SATA port for any of these tests.

You can use either. USB or SATA are not that critical for this. Stay with the current configuration.

Also, you wrote: " Once you have a bootable USB, connect both the HDD and SSD to the SATA bus, but still boot from the USB. The USB will not be CS, but the HDD and SSD will be.." Are you referring only to the 16GB flash drive OS X installation from the recovery console not being CS?

Yes.

Your last paragraph said: "There is a much simpler test that you can perform, without touching the original SSD. Connect your HDD (to the SATA port or to the other USB port?), boot from the external USB Flash drive (warning - this is very slow). Run diskutil cs revert on the HDD only. Now try and connect both SSD and HDD to SATA bus (wha?! If the SSD is connected it'll be using the internal SATA port. Unless I use the optical drive's SATA port there isn't a SATA port available for the HDD copy) and test booting from all three."

I certainly like the idea of not modifying my SSD so thank you very much for coming up with an alternate plan. See my questions in italics within the above quote.

USB or SATA is not very critical. Stay with the current HW configuration.

Since your new proposed plan does not include disabling CS on the original SSD, and then making a copy of it, it sounds to me like we're just trying to disable CS in one of the two otherwise identical drives (noting the GUID difference, too). If you believe that both drives using CS is the cause of my current inability to have both the HDD and the SSD connected simultaneously and Option-key boot from either, why don't I:

boot from the SSD

connect the HDD via USB after the MBP has booted

disable CS on the HDD from Terminal

shutdown

power up, hold down Option key, and try booting from the HDD

The CS SSD will be SATA. The JHFS+ HDD will be USB. Is it worth a try? We're using the HDD for two things: to test the integrity of a TB IFL clone and to test a few methods for fixing my Yosemite-upgrade-clobbered-Bootcamp capability. I'm not going to use the HDD beyond that so I don't care about disabling CS on it -- unless it invalidates any of these tests.

In addition, you are also going to boot from the USB flash disk with the SSD (with CS) and HDD (no CS) connected.

trwd Author

Level 1

17 points

Oct 1, 2015 6:48 AM in response to Loner T

(re the last sentence in your reply: "In addition, you are also going to boot...")

Ah, so the goal is to test booting from the USB flash drive. Got it.

While you didn't say yes or no to my idea of disabling CS on the HDD I see that you wrote "HDD (no CS)" so I assume you think it's worth a try. Let me know if not. I won't be able to do this until later today.

Loner T

Level 9

59,477 points

Oct 1, 2015 7:01 AM in response to trwd

trwd wrote:

(re the last sentence in your reply: "In addition, you are also going to boot...")

Ah, so the goal is to test booting from the USB flash drive. Got it.

While you didn't say yes or no to my idea of disabling CS on the HDD I see that you wrote "HDD (no CS)" so I assume you think it's worth a try. Let me know if not. I won't be able to do this until later today.

In one of my previous reposes, I had

Run diskutil cs revert on the HDD only.

Yes, only revert the HDD to non-CS and test connecting both with a USB Flash boot device, and then test booting individually from the HDD and SSD. Bootcamp from the clones external HDD is unlikely to work due to Windows restrictions. Test when you can. 😉

trwd Author

Level 1

17 points

Oct 2, 2015 12:47 PM in response to Loner T

I'm back and ready to run "diskutil cs revert" on the HDD but I don't know how to get the correct UUID for the HDD. You wrote previously:

diskutil cs revert F6545BAB-5B31-4838-A188-C59D210B12FB

(The UUID came from your diskutil cs list output). This will expose the underlying JHFS+ volume which is a regular partition on disk. You can clone the disk using Terabyte or at least try and it and test it.

I ran "diskutil cs list" and got the following results but I don't understand the hierarchical structure of the report.

Last login: Fri Oct 2 12:31:09 on console

diskutil cs list

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group B8FA8874-F8C3-4EC1-8F53-0F555EDFC166

=========================================================

Name: Macintosh HD

Status: Online

Size: 255250432000 B (255.3 GB)

Free Space: 18907136 B (18.9 MB)

|

+-< Physical Volume 84E5E470-49E8-4585-AA1D-397BDEA61A3D

| ----------------------------------------------------

| Index: 0

| Disk: disk0s2

| Status: Online

| Size: 255250432000 B (255.3 GB)

|

+-> Logical Volume Family E409753F-A5B6-4DAC-BF6F-17CE4956E11E

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

Encryption Status: Unlocked

Encryption Type: None

Conversion Status: NoConversion

Conversion Direction: -none-

Has Encrypted Extents: No

Fully Secure: No

Passphrase Required: No

|

+-> Logical Volume F6545BAB-5B31-4838-A188-C59D210B12FB

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

Disk: disk1

Status: Online

Size (Total): 254879203328 B (254.9 GB)

Conversion Progress: -none-

Revertible: Yes (no decryption required)

LV Name: Macintosh HD

Volume Name: Macintosh HD

Content Hint: Apple_HFS

Since the last 4 digits of the UUID match the UUID of a logical volume on disk1 (the SSD), I assume I'm looking for its equivalent on the HDD.

Please advise. BTW, at one point I asked you what "Disk1" refers to since in reality there are two physical disks: Disk0 (SSD) and Disk2 (HDD - USB). Would you mind digressing briefly and telling me how to interpret the above report -- or is it incomplete? Thanks.

Loner T

Level 9

59,477 points

Oct 2, 2015 1:02 PM in response to trwd

Is this output with the HDD connected or just the SSD?

trwd wrote:

BTW, at one point I asked you what "Disk1" refers to since in reality there are two physical disks: Disk0 (SSD) and Disk2 (HDD - USB). Would you mind digressing briefly and telling me how to interpret the above report -- or is it incomplete? Thanks.

Disk1 is a virtual disk which is contained within the LVG. The hierarchy is explained in the Man page of diskutil. You can also see it in https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/ man8/diskutil.8.html in the CoreStorage section.

trwd Author

Level 1

17 points

Oct 2, 2015 1:25 PM in response to trwd

The following is with the internal SSD connected to SATA and the external HDD clone -- ready to have Corestorage disabled using "convert" - connected to one of the USB 3 ports on my MBP.

I ran "diskutil cs list" and got the following results but I don't understand if the desired UUID is listed.

Last login: Fri Oct 2 12:31:09 on console

diskutil cs list

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group B8FA8874-F8C3-4EC1-8F53-0F555EDFC166

=========================================================

Name: Macintosh HD

Status: Online

Size: 255250432000 B (255.3 GB)

Free Space: 18907136 B (18.9 MB)

|

+-< Physical Volume 84E5E470-49E8-4585-AA1D-397BDEA61A3D

| ----------------------------------------------------

| Index: 0

| Disk: disk0s2

| Status: Online

| Size: 255250432000 B (255.3 GB)

|

+-> Logical Volume Family E409753F-A5B6-4DAC-BF6F-17CE4956E11E

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

Encryption Status: Unlocked

Encryption Type: None

Conversion Status: NoConversion

Conversion Direction: -none-

Has Encrypted Extents: No

Fully Secure: No

Passphrase Required: No

|

+-> Logical Volume F6545BAB-5B31-4838-A188-C59D210B12FB

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

Disk: disk1

Status: Online

Size (Total): 254879203328 B (254.9 GB)

Conversion Progress: -none-

Revertible: Yes (no decryption required)

LV Name: Macintosh HD

Volume Name: Macintosh HD

Content Hint: Apple_HFS

Loner T

Level 9

59,477 points

Oct 2, 2015 2:36 PM in response to trwd

If the external disk is connected, we should see it's CS entry as well. Does diskutil list show both disks connected? If yes, do they both show up as Corestorage volumes? If they were cloned, you may have a CS UUID conflict. Check for any errors in Applications -> Utilities -> Console logs.

trwd Author

Level 1

17 points

Oct 2, 2015 3:05 PM in response to Loner T

/dev/disk0

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *512.1 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_CoreStorage 255.3 GB disk0s2

3: Apple_Boot Recovery HD 650.0 MB disk0s3

4: Microsoft Basic Data BOOTCAMP 255.5 GB disk0s4

/dev/disk1

#: TYPE NAME SIZE IDENTIFIER

0: Apple_HFS Macintosh HD *254.9 GB disk1

Logical Volume on disk0s2

F6545BAB-5B31-4838-A188-C59D210B12FB

Unencrypted

/dev/disk2

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.5 TB disk2

1: EFI EFI 209.7 MB disk2s1

2: Apple_CoreStorage 255.3 GB disk2s2

3: Apple_Boot Recovery HD 650.0 MB disk2s3

4: Microsoft Basic Data BOOTCAMP 255.5 GB disk2s4

Bootcamp booting clobbered by Yosemite upgrade