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 9:53 AM in response to Loner T

I'd like to relay your comments to Terabyte but want to be sure I understand at least a little of what you're saying.

There is roughly 900+ GB free at the end. Say 'y' to that relocation question and let Gdisk re-locate the Secondary GPT to the end of the disk. This can also be clarified with the Terabyte support folks that they made an exact bit-by-bit copy, which left the secondary GPT in the same location as the original disk, which could be feature/bug depending on your perspective.

Did you compare the two GPT listings I provided previously? Do they indicate any relevant differences between the copy and the original other than the fact that the copy is on a 1.5TB HDD?

To make a bootable copy I used a feature in Terabyte's Image for Linux called "copy unused sectors". I don't know if that's a bit-by-bit copy but I can ask if you think I should.

In your last sentence above are you saying it's good or bad that Terabyte IFL left the secondary GPT in the same location as the original disk? I figured my goal should be to create an exact copy for experimenting on (e.g., trying to fix Bootcamp per this thread) and ignore the remaining space on the copy.

Lastly, will it matter at any point in the future if I let Gdisk relocate the Secondary GPT to the end of the disk -- like when upgrading from Yosemite to El Capitan? Being ignorant about the inner workings of OSX and Linux I'm averse to changing anything that Apple's software might not like. 😕

Loner T

Level 9

59,477 points

Sep 30, 2015 10:40 AM in response to trwd

trwd wrote:

I'd like to relay your comments to Terabyte but want to be sure I understand at least a little of what you're saying.

There is roughly 900+ GB free at the end. Say 'y' to that relocation question and let Gdisk re-locate the Secondary GPT to the end of the disk. This can also be clarified with the Terabyte support folks that they made an exact bit-by-bit copy, which left the secondary GPT in the same location as the original disk, which could be feature/bug depending on your perspective.

Did you compare the two GPT listings I provided previously? Do they indicate any relevant differences between the copy and the original other than the fact that the copy is on a 1.5TB HDD?

Since you are going from a smaller (500Gb) to a larger (1500Gb) disk, the clone process is laying down the source sectors at the same location on the target disk. If you look at the start/size pairs, they are the same. This would explain the gap at the end of the disk (1000+Gb).

To make a bootable copy I used a feature in Terabyte's Image for Linux called "copy unused sectors". I don't know if that's a bit-by-bit copy but I can ask if you think I should.

I think you should clarify with the software vendor. It is always helpful to understand the process as much as possible.

In your last sentence above are you saying it's good or bad that Terabyte IFL left the secondary GPT in the same location as the original disk? I figured my goal should be to create an exact copy for experimenting on (e.g., trying to fix Bootcamp per this thread) and ignore the remaining space on the copy.

The software does meet your requirements to the letter.

Lastly, will it matter at any point in the future if I let Gdisk relocate the Secondary GPT to the end of the disk -- like when upgrading from Yosemite to El Capitan? Being ignorant about the inner workings of OSX and Linux I'm averse to changing anything that Apple's software might not like.

If you relocate the secondary GPT to the end of the disk, all future upgrades will work pro rely on the larger disk. It can cause problems, if not done now. Apple's software expects the GPT layout to match the GPT specifications. Please see https://en.wikipedia.org/wiki/GUID_Partition_Table for the design of the GPT and who the primary and secondary (or backup) GPT tables are managed.

trwd Author

Level 1

17 points

Sep 30, 2015 10:47 AM in response to Loner T

I changed the GUID of the external HDD and shut everything down. Then I powered up the external USB HDD followed by booting the MBP. Held the Option key down after the chime. Both drives were visible as boot choices. I selected the external USB HDD to boot from and the system booted.

I believe the system still booted from the SSD. I suspect this because previously, when the internal SSD was physically disconnected from the MBP and I booted from the HDD I could hear the HDD making the usual mechanical noises any spinner makes during this kind of activity.

The SSD is still internally connected and even though I selected the HDD to boot from the HDD remained silent (except for its spinning noise) during bootup. Is there a terminal command I can use to tell which drive the system booted from?

Here's the results of my fetching the GUID's from both drives, which indicates that Gdisk successfully changed the GUID of the HDD.

sudo gdisk -l /dev/disk0

Password:

GPT fdisk (gdisk) version 1.0.0

Warning: Devices opened with shared lock will not have their

partition table automatically reloaded!

Partition table scan:

MBR: protective

BSD: not present

APM: not present

GPT: present

Found valid GPT with protective MBR; using GPT.

Disk /dev/disk0: 1000215216 sectors, 476.9 GiB

Logical sector size: 512 bytes

Disk identifier (GUID): 02445E37-1F51-4E77-91B0-00DEC704C5D7

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 1000215182

Partitions will be aligned on 8-sector boundaries

Total free space is 922893 sectors (450.6 MiB)

Number Start (sector) End (sector) Size Code Name

1 40 409639 200.0 MiB EF00 EFI System Partition

2 409640 498945639 237.7 GiB AF05 Macintosh HD

3 498945640 500215175 619.9 MiB AB00 Recovery HD

4 500215808 999292927 238.0 GiB 0700 BOOTCAMP

sudo gdisk -l /dev/disk2

Password:

GPT fdisk (gdisk) version 1.0.0

Warning: Devices opened with shared lock will not have their

partition table automatically reloaded!

Partition table scan:

MBR: protective

BSD: not present

APM: not present

GPT: present

Found valid GPT with protective MBR; using GPT.

Disk /dev/disk2: 2930277168 sectors, 1.4 TiB

Logical sector size: 512 bytes

Disk identifier (GUID): 08427A04-203B-4751-8D30-E829EFBD993E

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 2930277134

Partitions will be aligned on 8-sector boundaries

Total free space is 1930984845 sectors (920.8 GiB)

Number Start (sector) End (sector) Size Code Name

1 40 409639 200.0 MiB EF00 EFI System Partition

2 409640 498945639 237.7 GiB AF05 Macintosh HD

3 498945640 500215175 619.9 MiB AB00 Recovery HD

4 500215808 999292927 238.0 GiB 0700 BOOTCAMP

Loner T

Level 9

59,477 points

Sep 30, 2015 10:54 AM in response to trwd

Run diskutil list and post the output.

trwd Author

Level 1

17 points

Sep 30, 2015 11:02 AM in response to Loner T

I think a typo crept into your reply.

If you relocate the secondary GPT to the end of the disk, all future upgrades will work pro rely on the larger disk. It (?) can cause problems, if not done now. Apple's software expects the GPT layout to match the GPT specifications.

Am I to understand that by having relocated the secondary GPT to the end of the disk the HDD copy is now consistent with Apple's expectations, and related problems will be avoided? If so, then later when I write about my success using Terabyte Image for Linux I should include instructions for relocating the GPT to the end of the disk, correct? (and what would the commands be? -- if the user has no need to change the GUID on the copy but does want the relocation done for future compatibility).

trwd Author

Level 1

17 points

Sep 30, 2015 11:00 AM in response to Loner T

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

/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

Loner T

Level 9

59,477 points

Sep 30, 2015 11:02 AM in response to trwd

It should say properly . 😉

trwd wrote:

Am I to understand that by having relocated the secondary GPT to the end of the disk the HDD copy is now consistent with Apple's expectations, and related problems will be avoided? If so, then later when I write about my success using Terabyte Image for Linux I should include instructions for relocating the GPT to the end of the disk, correct (and what would the commands be? -- if the user has no need to change the GUID on the copy but does want the relocation done for future compatibility).

You can use the Gdisk commands as indicated and when prompted for the relocation of the GPT part, answer 'y'es. This would allow the clone destination to work properly in the future.

trwd Author

Level 1

17 points

Sep 30, 2015 11:06 AM in response to Loner T

You can use the Gdisk commands as indicated and when prompted for the relocation of the GPT part, answer 'y'es. This would allow the clone destination to work properly in the future.

So you're saying to change the GUID on the copy, which will lead to the opportunity to relocate the Secondary GPT?

Loner T

Level 9

59,477 points

Sep 30, 2015 11:18 AM in response to trwd

To find out which disk you booted from, you can run the following two highlighted commands. The highlighted disk is your boot disk.

1. df -h

2. diskutil info /

Loner T

Level 9

59,477 points

Sep 30, 2015 11:51 AM in response to trwd

trwd wrote:

You can use the Gdisk commands as indicated and when prompted for the relocation of the GPT part, answer 'y'es. This would allow the clone destination to work properly in the future.

So you're saying to change the GUID on the copy, which will lead to the opportunity to relocate the Secondary GPT?

Yes.

trwd Author

Level 1

17 points

Sep 30, 2015 1:20 PM in response to Loner T

Thank you for trying to show me how to determine which of two disks my MBP booted from.

You wrote:

To find out which disk you booted from, you can run the following two highlighted commands. The highlighted disk is your boot disk.

1. df -h

2. diskutil info /

I'm curious why two commands are used to do this and what you mean by "the highlighted disk". In the results below it's not clear to me what specifically indicates the boot disk. I'm also curious what Disk1 refers to when there are only two physical disks: Disk0 and Disk2.

df -h

Filesystem Size Used Avail Capacity iused ifree %iused Mounted on

/dev/disk1 237Gi 129Gi 108Gi 55% 33871196 28355170 54% /

devfs 188Ki 188Ki 0Bi 100% 650 0 100% /dev

/dev/disk0s4 238Gi 79Gi 159Gi 34% 226985 166903311 0% /Volumes/BOOTCAMP

map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net

map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home

/dev/disk2s4 238Gi 79Gi 159Gi 34% 226985 166903311 0% /Volumes/BOOTCAMP 1

diskutil info /

Device Identifier: disk1

Device Node: /dev/disk1

Part of Whole: disk1

Device / Media Name: Macintosh HD

Volume Name: Macintosh HD

Mounted: Yes

Mount Point: /

File System Personality: Journaled HFS+

Type (Bundle): hfs

Name (User Visible): Mac OS Extended (Journaled)

Journal: Journal size 40960 KB at offset 0xee7000

Owners: Enabled

Content (IOContent): Apple_HFS

OS Can Be Installed: Yes

Recovery Disk: disk0s3

Media Type: Generic

Protocol: SATA

SMART Status: Not Supported

Volume UUID: 43D11CC9-E023-3B57-BB38-65F4C8E23CC9

Disk / Partition UUID: F6545BAB-5B31-4838-A188-C59D210B12FB

Total Size: 254.9 GB (254879203328 Bytes) (exactly 497810944 512-Byte-Units)

Volume Free Space: 116.1 GB (116142776320 Bytes) (exactly 226841360 512-Byte-Units)

Device Block Size: 512 Bytes

Allocation Block Size: 4096 Bytes

Read-Only Media: No

Read-Only Volume: No

Ejectable: No

Whole: Yes

Internal: Yes

Solid State: Yes

OS 9 Drivers: No

Low Level Format: Not supported

This disk is a Core Storage Logical Volume (LV). Core Storage Information:

LV UUID: F6545BAB-5B31-4838-A188-C59D210B12FB

LVF UUID: E409753F-A5B6-4DAC-BF6F-17CE4956E11E

LVG UUID: B8FA8874-F8C3-4EC1-8F53-0F555EDFC166

Fusion Drive: No

Encrypted: No

trwd Author

Level 1

17 points

Sep 30, 2015 2:26 PM in response to Loner T

Loner T, does anything in the results below explain why I cannot boot from the external USB HDD while the internal SSD is connected -- even though I changed the HDD's GUID?

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

/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

Loner T

Level 9

59,477 points

Sep 30, 2015 2:46 PM in response to trwd

Yes, it does. We need to diskutil cs revert on the source disk and then clone it and then test booting. The source and destination being CS volumes is problematic as your contact with the Cloning software vendor indicates.

If both the source and destination disks became CS volumes after cloning, it is even more puzzling.

Was the source disk reverted prior to cloning?

trwd Author

Level 1

17 points

Sep 30, 2015 3:58 PM in response to Loner T

First, please know that I greatly appreciate your help here. It is unbelievably gracious of you. Can you help me understand where the following line of reasoning runs off the track?

The HDD copy appears to be identical to the original, and I think you agreed with this earlier today. Doesn't this mean that Terabyte Image for Linux did a good job of cloning the original drive with the exception that the Secondary GPT must be moved to the end of the drive? I had hoped to pin that and move on.

But...

The HDD copy boots fine only when the internal SSD is disconnected from the system. It's a hassle to disconnect the battery and SSD every time I want to switch between booting from the SSD and the HDD so I wondered what prevents both drives from being connected and booting from either.

The Terabyte support tech and I speculated that Macs can't handle two drives having the same GUID, just as Windows PCs cannot tolerate two physical drives with the same Volume ID/Serial Number. So I asked you how to change the GUID, which you helped me do today.

To me the threshold question is: was I wrong believing that the identical GUID's was the obstacle to keeping both drives connected?

Since I have now changed the drive GUID there must be some other obstacle to having both connected. Any idea what it is?

The source disk SSD was NOT reverted prior to cloning. It is unchanged and CoreStorage is still intact. Is the fact that both drives use CoreStorage the reason they both cannot coexist?

Loner T

Level 9

59,477 points

Sep 30, 2015 4:36 PM in response to trwd

trwd wrote:

The HDD copy appears to be identical to the original, and I think you agreed with this earlier today. Doesn't this mean that Terabyte Image for Linux did a good job of cloning the original drive with the exception that the Secondary GPT must be moved to the end of the drive? I had hoped to pin that and move on.

Yes. TBIL did an excellent job. The reason you are seeing the secondary GPT message is because in a sector-by-sector copy, the Secondary GPT is placed on the destination disk at the same exact sector where it was on the source disk. This sector is not the end of the destination disk and violates the GPT design principles. GPT secondary are kept 32 sectors from the physical end of last sector. You can see this on the source disk. Here is my disk as an example.

sudo gpt -vv -r show /dev/disk0

Password:

gpt show: /dev/disk0: mediasize=256060514304; sectorsize=512; blocks=500118192

gpt show: /dev/disk0: Suspicious MBR at sector 0

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

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

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 250392096 2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC

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

252071272 664

252071936 248045568 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

500117504 655

500118159 32 Sec GPT table

500118191 1 Sec GPT header

The HDD copy boots fine only when the internal SSD is disconnected from the system. It's a hassle to disconnect the battery and SSD every time I want to switch between booting from the SSD and the HDD so I wondered what prevents both drives from being connected and booting from either.

The Terabyte support tech and I speculated that Macs can't handle two drives having the same GUID, just as Windows PCs cannot tolerate two physical drives with the same Volume ID/Serial Number. So I asked you how to change the GUID, which you helped me do today.

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.

To me the threshold question is: was I wrong believing that the identical GUID's was the obstacle to keeping both drives connected?

Since I have now changed the drive GUID there must be some other obstacle to having both connected. Any idea what it is?

The source disk SSD was NOT reverted prior to cloning. It is unchanged and CoreStorage is still intact. Is the fact that both drives use CoreStorage the reason they both cannot coexist?

We should first revert the CS to base JHFS+ partition on the source, and then clone to destination. After the cloning is complete, change Disk GUIDs, and then test booting with both connected to the Mac. There is a verbose mode (invoked using Command+V - Startup key combinations for Mac - Apple Support) during boot, which should be invoked for the clone to see if there are any other errors that need to be addressed.

I want to see this working as well. 😉

Bootcamp booting clobbered by Yosemite upgrade