trwd

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

Close

Q: Bootcamp booting clobbered by Yosemite upgrade

  • All replies
  • Helpful answers

first Previous Page 4 of 5 last Next
  • by Loner T,

    Loner T Loner T Sep 30, 2015 4:36 PM in response to trwd
    Level 7 (24,307 points)
    Safari
    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.

  • by trwd,

    trwd trwd Sep 30, 2015 5:53 PM in response to Loner T
    Level 1 (15 points)
    Audio
    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.

  • by trwd,

    trwd trwd Sep 30, 2015 5:55 PM in response to Loner T
    Level 1 (15 points)
    Audio
    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?

  • by Loner T,

    Loner T Loner T Sep 30, 2015 5:55 PM in response to trwd
    Level 7 (24,307 points)
    Safari
    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.

  • by Loner T,

    Loner T Loner T Sep 30, 2015 5:58 PM in response to trwd
    Level 7 (24,307 points)
    Safari
    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.

  • by trwd,

    trwd trwd Sep 30, 2015 7:07 PM in response to Loner T
    Level 1 (15 points)
    Audio
    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?

  • by Loner T,

    Loner T Loner T Sep 30, 2015 7:45 PM in response to trwd
    Level 7 (24,307 points)
    Safari
    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.

  • by trwd,

    trwd trwd Sep 30, 2015 9:21 PM in response to Loner T
    Level 1 (15 points)
    Audio
    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:

     

    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.



  • by Loner T,

    Loner T Loner T Oct 1, 2015 4:10 AM in response to trwd
    Level 7 (24,307 points)
    Safari
    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:

     

    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.

  • by trwd,

    trwd trwd Oct 1, 2015 6:48 AM in response to Loner T
    Level 1 (15 points)
    Audio
    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.

  • by Loner T,

    Loner T Loner T Oct 1, 2015 7:01 AM in response to trwd
    Level 7 (24,307 points)
    Safari
    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.

  • by trwd,

    trwd trwd Oct 2, 2015 12:47 PM in response to Loner T
    Level 1 (15 points)
    Audio
    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.

  • by Loner T,

    Loner T Loner T Oct 2, 2015 1:02 PM in response to trwd
    Level 7 (24,307 points)
    Safari
    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.

  • by trwd,

    trwd trwd Oct 2, 2015 1:25 PM in response to trwd
    Level 1 (15 points)
    Audio
    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

  • by Loner T,

    Loner T Loner T Oct 2, 2015 2:36 PM in response to trwd
    Level 7 (24,307 points)
    Safari
    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.

first Previous Page 4 of 5 last Next