Bootcamp booting clobbered by Yosemite upgrade

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 wrote:

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.

This can happen if the installation is a BIOS/MBR and the MBR is missing. How do you get to start Windows if this option is missing?

Worse, when I set "Startup Disk" to Bootcamp Windows the result fails.

This is because the bless command has failed. Do you have any third-partty NTFS software? Can you also check Applications -> Utilities -> Console for any bootcamp-related entries.

What year/model is Mac? Any Mac prior to Late 2013 models, is usually a MBR/BIOS installation and requires a Hybrid MBR, which is missing in your case. Later models support both UEFI and BIOS booting. EFI Boot also requires a MSR partition on the GPT-only disks.

Can you also run the following two procedures and test?

Resetting the System Management Controller (SMC) on your Mac - Apple Support

How to Reset NVRAM on your Mac - Apple Support

Yes, a Mac will boot OSX from an external drive. See How to install OS X on an external drive connected to your Mac - Apple Support as an example. You can boot form the internal disk which si working, attach the clone a san external disk and use a utility like GPT or GPT Fdisk to examine GUIDs on each disk.

Clonezilla may use methods like U*ix DD to make an exact replica, including the GUIDs.

GPT Command

sudo gpt -vv -r show /dev/disk0

Password:

gpt show: /dev/disk0: mediasize=1000555581440; sectorsize=512; blocks=1954210120

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 1954210119

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 1448624648 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC

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

1450303824 1712

1450305536 503904256 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

1954209792 295

1954210087 32 Sec GPT table

1954210119 1 Sec GPT header

GPT Fdisk Commands

sudo gdisk -l /dev/disk0

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: hybrid

BSD: not present

APM: not present

GPT: present

Found valid GPT with hybrid MBR; using GPT.

Disk /dev/disk0: 1954210120 sectors, 931.8 GiB

Logical sector size: 512 bytes

Disk identifier (GUID): 6ED0C429-00D1-4759-B50E-04B6FB80D0E3

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 1954210086

Partitions will be aligned on 8-sector boundaries

Total free space is 2013 sectors (1006.5 KiB)

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

1 40 409639 200.0 MiB EF00 EFI System Partition

2 409640 1449034287 690.8 GiB AF00 Customer

3 1449034288 1450303823 619.9 MiB AB00 Recovery HD

4 1450305536 1954209791 240.3 GiB 0700 BOOTCAMP

sudo gdisk /dev/disk0

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: hybrid

BSD: not present

APM: not present

GPT: present

Found valid GPT with hybrid MBR; using GPT.

Command (? for help): p

Disk /dev/disk0: 1954210120 sectors, 931.8 GiB

Logical sector size: 512 bytes

Disk identifier (GUID): 6ED0C429-00D1-4759-B50E-04B6FB80D0E3

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 1954210086

Partitions will be aligned on 8-sector boundaries

Total free space is 2013 sectors (1006.5 KiB)

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

1 40 409639 200.0 MiB EF00 EFI System Partition

2 409640 1449034287 690.8 GiB AF00 Customer

3 1449034288 1450303823 619.9 MiB AB00 Recovery HD

4 1450305536 1954209791 240.3 GiB 0700 BOOTCAMP

Command (? for help): i

Partition number (1-4): 1

Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)

Partition unique GUID: 9BE44DE5-9AA9-4F22-9DDF-B6D13A28C14A

First sector: 40 (at 20.0 KiB)

Last sector: 409639 (at 200.0 MiB)

Partition size: 409600 sectors (200.0 MiB)

Attribute flags: 0000000000000000

Partition name: 'EFI System Partition'

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. 😉

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 wrote:

After shutting down again I installed the SSD and booted with both drives connected (Option key held down). Three drives appeared: the SSD "Macintosh HD", the HDD "Macintosh HD", and the HDD Recovery. I chose the HDD "Macintosh HD" because prior to disabling CS and changing the UUID the system would insist on booting from the SSD regardless of which drive I chose.

Can you run a SMC Reset and NVRAM Reset and then test booting from the HDD? Please also check the Console logs for any error messages.

/dev/disk2s2 238Gi 135Gi 102Gi 57% 35479200 26837798 57% /Volumes/Macintosh HD 1

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

This is the USB disk - disk2.

trwd wrote:

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

This shows that the boot was from a CS volume. Test with the SMC and NVRam reset.

Resetting the System Management Controller (SMC) on your Mac - Apple Support

How to Reset NVRAM on your Mac - Apple Support

Rebuild MBR to match the new GPT information thus resetting the Hybrid MBR. Use defaults for other questions (like partition codes). The only values that need modifications are the Boot flags and step 10. Accept all other defaults that Gdisk offers. Please see thesample Q&A as an example. These steps can be repeated if you make a mistake before you get to Step 12, otherwise start from Step 1 for these steps. Step 6 has numbers which are typed with a space between the numbers. Please see the sample Q&A before you execute these steps.

1. Sudo gdisk /dev/rdisk0
2. P (Print list of parts)
3. R (Recover)
4. O (print current Hybrid MBR)
5. H (chooses Hybrid)
6. Partitions numbers to be hybridized: 2 3 4
7. Y (Good for GRUB question)
8. N (part 2 boot flag)
9. N (part 3 boot flag)
10. Y (part 4 boot flag make NTFS bootable partition)
11. O (print current Hybrid MBR)
12. W (Write the new MBR)
13. Y (Yes! write the new MBR)
14. Reboot

Here is sample Q&A for this section. Please notice the Press Enter/Return.

Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): Y

Creating entry for GPT partition #2 (MBR partition #2)

Enter an MBR hex code (default AF): Press Enter/Return

Set the bootable flag? (Y/N): N

Creating entry for GPT partition #3 (MBR partition #3)

Enter an MBR hex code (default AB): Press Enter/Return

Set the bootable flag? (Y/N): N

Creating entry for GPT partition #4 (MBR partition #4)

Enter an MBR hex code (default 07): Press Enter/Return

Set the bootable flag? (Y/N): Y

Some of the following tests (1,2) may already be working in your specific case.

Test 1 - Does Bootcamp Volume show up in Finder?

Test 2 - Can you see files in Bootcamp Volume?

Test 3 - Can you select Bootcamp in System Preferences -> Startup Disk?

Test 4 - If Test 3 is successful, select Bootcamp and Click Restart.

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:

1. boot from the SSD
2. connect the HDD via USB after the MBP has booted
3. disable CS on the HDD from Terminal
4. shutdown
5. 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.

Based on what you have posted, you seem to have an EFI installation. Your Mac does not fully support UEFI standard. Can you run msinfo32 and check of the following information?