Caution - Yosemite may screw up partitions.

campyguy · Jun 9, 2014

BasicGreatGuy said:
Camp,
If you don't mind, can you post the two commands again and explain them in layman's terms, so someone (like me) who isn't familiar with terminal commands (as a whole) can understand the proper steps? I am not sure I am following.

Thanks

That's "campy" for short! As in Campagnolo, a cycling component manufacturer of which I have given far too much money over 30-odd years...

In short, what happened in short is that the result of setting up our Mac's drives with multiple partitions is we're left with an Logical Volume (LV) and Logical Volume Group (LVG) - think "Fusion Drive". Disk Utility has, for some reason, created an LV out of multiple-partition-drives on which Yosemite has been installed on one of those partitions. This "issue" is not new, and has occurred since Lion came out, about the same time Fusion Drives were coming out IMO. Ahem. Bug. Cough...

Refer to two posts, my #36 and DougApple's #31 (specifically, the Terminal output screen shot).

In my post #36, the first Terminal command yields output identical to DougApple's Terminal screen shot in cases like those described in this thread. From the BSD Manual, the first Terminal command "Display a tree view of the CoreStorage world for all current logical groups (LVGs) with member disks (PVs) and exported volumes (LVFs and LVs), properties and status for each level." In lay terms, the "diskutil cs list" command returns the information and status of a corestorage LVG (you'll get "No CoreStorage logical volume groups found" for non-LVG setups like your normally-formatted disk/partition(s). You're asking for an "informational list" of your "corestorage LVG" by "Disk Utility" via the "diskutil cs list" command. The results are as shown in DougApple's screen shot. For the next command, you'll want the lvUUID that's shown in that screen shot - the lvUUID, or Logical Volume UUID of the LV (the last lvUUID in that screen shot), as that's the volume (partition) you want to revert.

In that screen shot, there's one key bit - the word "Yes" next to "Revertible". What follows "Yes" doesn't matter so much - the encryption part describes whether your partition is password-protected or not, and Terminal will prompt for that password or a Keychain file during the second Terminal command, depending on how it's protected.

The second Terminal command, "diskutil coreStorage revert lvUUID" - from the BSD Manual: "Convert a CoreStorage logical volume back to its native type. The volume must have been created by means of conversion, e.g. with diskutil coreStorage convert." It seems as it's something in the Mavericks Disk Utility app or other process within the Yosemite installer is executing this "diskutil coreStorage convert" command - and I'm not intending to watch either process in verbose mode (a snarky, but true, joke

). The "diskutil coreStorage revert lvUUID" Terminal command in my post #36 "undoes" that "convert" command.

For DougApple's situation, you'd type (without the quotes) "diskutil coreStorage revert 47F9D6B1-F8F2-4E64-8AD4-92FE2BD78E29" - of course, one can copy that text string directly from the results of the first Terminal command.

Keep in mind that the second Terminal command is non-destructive - it won't break or overwrite anything. I saw this thread, and a second thread, decided to check my current Mac and found the same LV situation, switched to an Admin account, typed in the two commands waited 1 and 3 seconds, respectively, rechecked and found two Mac OS Extended (Journaled) formatted partitions (as I'd expected after the Yosemite install), logged out and went back to work. I have two working partitions, and used the Yosemite partition this morning.

I encourage you to look at the two links I included in my post #36 - Foskett's blog post should assuage all concerns you may have. The first time I used the "revert" command - I did hold my breath, I'll admit, but it worked. Linux users have those commands available to them as well, specifically for LVs and LVGs.

I've done my part, now it's time for a shot of bourbon!

Apple_Robert · Jun 9, 2014

campyguy said:
That's "campy" for short! As in Campagnolo, a cycling component manufacturer of which I have given far too much money over 30-odd years...

In short, what happened in short is that the result of setting up our Mac's drives with multiple partitions is we're left with an Logical Volume (LV) and Logical Volume Group (LVG) - think "Fusion Drive". Disk Utility has, for some reason, created an LV out of multiple-partition-drives on which Yosemite has been installed on one of those partitions. This "issue" is not new, and has occurred since Lion came out, about the same time Fusion Drives were coming out IMO. Ahem. Bug. Cough...

Refer to two posts, my #36 and DougApple's #31 (specifically, the Terminal output screen shot).

In my post #36, the first Terminal command yields output identical to DougApple's Terminal screen shot in cases like those described in this thread. From the BSD Manual, the first Terminal command "Display a tree view of the CoreStorage world for all current logical groups (LVGs) with member disks (PVs) and exported volumes (LVFs and LVs), properties and status for each level." In lay terms, the "diskutil cs list" command returns the information and status of a corestorage LVG (you'll get "No CoreStorage logical volume groups found" for non-LVG setups like your normally-formatted disk/partition(s). You're asking for an "informational list" of your "corestorage LVG" by "Disk Utility" via the "diskutil cs list" command. The results are as shown in DougApple's screen shot. For the next command, you'll want the lvUUID that's shown in that screen shot - the lvUUID, or Logical Volume UUID of the LV (the last lvUUID in that screen shot), as that's the volume (partition) you want to revert.

In that screen shot, there's one key bit - the word "Yes" next to "Revertible". What follows "Yes" doesn't matter so much - the encryption part describes whether your partition is password-protected or not, and Terminal will prompt for that password or a Keychain file during the second Terminal command, depending on how it's protected.

The second Terminal command, "diskutil coreStorage revert lvUUID" - from the BSD Manual: "Convert a CoreStorage logical volume back to its native type. The volume must have been created by means of conversion, e.g. with diskutil coreStorage convert." It seems as it's something in the Mavericks Disk Utility app or other process within the Yosemite installer is executing this "diskutil coreStorage convert" command - and I'm not intending to watch either process in verbose mode (a snarky, but true, joke ). The "diskutil coreStorage revert lvUUID" Terminal command in my post #36 "undoes" that "convert" command.

For DougApple's situation, you'd type (without the quotes) "diskutil coreStorage revert 47F9D6B1-F8F2-4E64-8AD4-92FE2BD78E29" - of course, one can copy that text string directly from the results of the first Terminal command.

Keep in mind that the second Terminal command is non-destructive - it won't break or overwrite anything. I saw this thread, and a second thread, decided to check my current Mac and found the same LV situation, switched to an Admin account, typed in the two commands waited 1 and 3 seconds, respectively, rechecked and found two Mac OS Extended (Journaled) formatted partitions (as I'd expected after the Yosemite install), logged out and went back to work. I have two working partitions, and used the Yosemite partition this morning.

I encourage you to look at the two links I included in my post #36 - Foskett's blog post should assuage all concerns you may have. The first time I used the "revert" command - I did hold my breath, I'll admit, but it worked. Linux users have those commands available to them as well, specifically for LVs and LVGs.

I've done my part, now it's time for a shot of bourbon!

Thank you, Campy

Your post was very helpful. I followed your directions and it worked as it was supposed to.

BrooklynAl · Jun 11, 2014

Have an issue with "invalid disk label"

I have a fusion drive and getting this error:

Verifying volume Macintosh HD
Checking storage systemChecking volume.
disk1s2: Scan for Volume Headers
disk0s2: Scan for Volume Headers
disk1s2: Scan for Disk Labels
Invalid Disk Label @ 758510219264: cksum mismatch
disk0s2: Scan for Disk Labels
Invalid Disk Label @ 120980459520: cksum mismatch
Logical Volume Group BAE9DD49-EBBF-4CC6-BE51-6A162FDB46A4 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 1609 MB Metadata Volume with double redundancy

Disk utility is indicating the HD is otherwise okay. Not sure how to correct the invalid label....I also have Yosemite on an external hard drive not sure if that is the cause or not.

paladawan · Jun 18, 2014

Hi,

I work with CloneZilla, and I experience the partition screw-up of the Yosemite Install. (from an USB bootable key).
To restore a partition with Clonezilla, the size has to be exactly the same, so I was not able to rollback to Maverick.

Here is the operation to :
- erase the Apple Boot Recovery partition
- merge the erase partition with the system partition to recover the original size.

These operations can not be managed through the GUI...

In a terminal :

STEP 1 : list the partition :

MacBook-Pro-de-paladawan-2:~ paladawan$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Mac OS 99.5 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_HFS MacData 80.0 GB disk0s4
5: Microsoft Basic Data IMAGES 319.6 GB disk0s5

STEP 2 :Erase the Recovery partition :

MacBook-Pro-de-paladawan-2:~ paladawan$ diskutil eraseVolume JHFS+ erasedpart disk0s3
Started erase on disk0s3 Recovery HD
Unmounting disk
Erasing
Initialized /dev/rdisk0s3 as a 620 MB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk

STEP 3 : Merge the erased partition with the system partition :

First check the erasedpart number :

MacBook-Pro-de-paladawan-2:~ paladawan$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Mac OS 99.5 GB disk0s2
3: Apple_HFS erasedpart 650.0 MB disk0s3
4: Apple_HFS MacData 80.0 GB disk0s4
5: Microsoft Basic Data IMAGES 319.6 GB disk0s5

Then merge it !

MacBook-Pro-de-paladawan-2:~ primx$ diskutil mergePartitions JHFS+ MacOS disk0s2 disk0s3
Merging partitions into a new partition
Start partition: disk0s2 Mac OS
Finish partition: disk0s3 erasedpart
Started partitioning on disk0
Merging partitions
Waiting for the disks to reappear
Growing disk
Finished partitioning on disk0
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Mac OS 100.0 GB disk0s2
3: Apple_HFS MacData 80.0 GB disk0s4
4: Microsoft Basic Data IMAGES 319.6 GB disk0s5
Finished erase on disk0s3 erasedpart

That's all !

TheBuffather · Jun 18, 2014

stiligFox said:
Is it possible the drive is encrypted? I've heard that if the drive is encrypted it changes the name of the physical disk. Maybe Yosemite does this by default?

The first beta mentioned issues with encrypted drives. I unencrypted my test machine before installing B1, and things went well. I would stay away from encryption via FileVault until the official release.

GrumpyTrucker · Jun 22, 2014

BrooklynAl said:
I have a fusion drive and getting this error:

Verifying volume Macintosh HD
Checking storage systemChecking volume.
disk1s2: Scan for Volume Headers
disk0s2: Scan for Volume Headers
disk1s2: Scan for Disk Labels
Invalid Disk Label @ 758510219264: cksum mismatch
disk0s2: Scan for Disk Labels
Invalid Disk Label @ 120980459520: cksum mismatch
Logical Volume Group BAE9DD49-EBBF-4CC6-BE51-6A162FDB46A4 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 1609 MB Metadata Volume with double redundancy

Disk utility is indicating the HD is otherwise okay. Not sure how to correct the invalid label....I also have Yosemite on an external hard drive not sure if that is the cause or not.

I can't help I'm afraid, but you sort of raised a point I was going to ask. I'm not a dev but did sign up for the public beta. I'm kinda hoping Apple sort the major issues by the time that rolls around, but if they've not I'll stay away. I'm occasionally reckless, not completely nuts.

I was planning on putting Yosemite on an external SSD just to get a feel of it before release, and see what it's like to be in near the beginning of an OS life. But after finding this thread about the installer creating Logical Volumes and Logical Volume Groups to build what are effectively Fusion Drives I was wondering how this behaviour might affect you if you already have a Fusion Drive.

I had assumed installing on an external would leave the primary partition untouched but your post Al makes me think that even putting 10.10 on an external drive is messing something up with the existing coreStorage LVG in some way, even if just marking the labels as invalid.

maflynn · Jun 23, 2014

GrumpyTrucker said:
I had assumed installing on an external would leave the primary partition untouched but your post Al makes me think that even putting 10.10 on an external drive is messing something up with the existing coreStorage LVG in some way, even if just marking the labels as invalid.

I've seen some talk here and elsewhere about 10.10 touching the internal partition even when installing on an external drive.

abcdefg12345 · Jun 23, 2014

Everything seems to be working fine for me on 2 drives

mavericks 10.9.3
yosemite dp2
windows 8.1

Screen Shot 2014-06-23 at 10.53.20 pm.png

GrumpyTrucker · Jun 23, 2014

maflynn said:
I've seen some talk here and elsewhere about 10.10 touching the internal partition even when installing on an external drive.

It was only seeing this thread that clued me in to the potential issue. I'd always assumed that if you were installing on an external then it was booting with OPTION that allowed you select boot device and as a result your internal partition wasn't touched. Sounds like 10.10 is currently doing some dual boot type stuff in the background. Maybe it's a bug. But it's one I'll be watching for news on before the public beta, especially with how it behaves with internal fusion drives.

As I said, occasionally reckless but not completely nuts. If it's still more than "acceptably" wonky at public beta time I'm not touching it

BrooklynAl · Jun 25, 2014

GrumpyTrucker said:
I can't help I'm afraid, but you sort of raised a point I was going to ask. I'm not a dev but did sign up for the public beta. I'm kinda hoping Apple sort the major issues by the time that rolls around, but if they've not I'll stay away. I'm occasionally reckless, not completely nuts.

I was planning on putting Yosemite on an external SSD just to get a feel of it before release, and see what it's like to be in near the beginning of an OS life. But after finding this thread about the installer creating Logical Volumes and Logical Volume Groups to build what are effectively Fusion Drives I was wondering how this behaviour might affect you if you already have a Fusion Drive.

I had assumed installing on an external would leave the primary partition untouched but your post Al makes me think that even putting 10.10 on an external drive is messing something up with the existing coreStorage LVG in some way, even if just marking the labels as invalid.

This appears to be an issue with the Yosemite and the fusion drive as far as I can tell. After repairing the disk several times with the single user mode. The cksum error resolved on the fusion drive (interestingly this did not happen on my 2010 iMac with a rotational drive). Though, after booting into the Yosemite partition, on my external hard drive, the problem recurred again. I therefore, felt the Yosemite partition and the fusion hard drive error are "true-true" and related. I then deleted the Yosemite partition and the cksum error at least for the time being has not recurred. Just as an aside, it turns out that there is very little information on check sum errors/disk mislabeling on the web. The Apple senior techs could not provide much help either.......although, that is unfortunately the case more often then not.

GrumpyTrucker · Jun 25, 2014

BrooklynAl said:
This appears to be an issue with the Yosemite and the fusion drive as far as I can tell. After repairing the disk several times with the single user mode. The cksum error resolved on the fusion drive (interestingly this did not happen on my 2010 iMac with a rotational drive). Though, after booting into the Yosemite partition, on my external hard drive, the problem recurred again. I therefore, felt the Yosemite partition and the fusion hard drive error are "true-true" and related. I then deleted the Yosemite partition and the cksum error at least for the time being has not recurred. Just as an aside, it turns out that there is very little information on check sum errors/disk mislabeling on the web. The Apple senior techs could not provide much help either.......although, that is unfortunately the case more often then not.

Sometimes you have to wonder if you should replace "could not provide much help" with "would not provide much help" I guess. I'll keep following for information. Thanks for the info

BrooklynAl · Jul 3, 2014

Yosemite and cksum error

Ever since I deleted the 10.10 partition on the external hard drive the check sum errors have not recurred on my iMac fusion drive. I deleted the 10.10 partition on the 25th of June.

I downloaded all the DP of Mavericks last year, and I never encountered this problem. Probably going to wait for the final release at this point.

KoolAid-Drink · Jul 8, 2014

Did anyone who downloaded and did a full install of DP3 still see this issue pop up (10.10's partition 'taking over' the entire HD)?

I'm hoping this has been resolved in DP3.

tywebb13 · Jul 12, 2014

There is no full installer for DP3, just a delta update.

The thing that resolves it is simply to do the following:

Run this in terminal to get your partitions back to normal. This will also make a recovery partition visible when you boot up when holding the option key down.

diskutil cs list

and then

diskutil coreStorage revert lvUUID

where lvUUID is the last lvUUID reported by the previous Terminal command.

You may have to restart for everything to get back to normal after you have run these commands in Terminal.

campyguy · Jul 12, 2014

KoolAid-Drink said:
Did anyone who downloaded and did a full install of DP3 still see this issue pop up (10.10's partition 'taking over' the entire HD)?

I'm hoping this has been resolved in DP3.

As tywebb13 offered, there is no full installer available for Yosemite yet, thus the creation of a Logical Group on partitioned hard drives will remain until the Installer is updated or replaced.

And, tywebb13, thanks for reiterating my earlier post. No restart is needed.

I used the Installer to install the DP on an external drive (a TB SSD), and the Installer created a Logical Group on the SSD.

The corestorage commands fixed that in seconds, tho'.

grahamperrin · Jul 13, 2014

Disk Utility, checksums, fsck_cs cksum mismatches and disk/storage problems

yjchua95 said:
Caution - Yosemite may screw up partitions.

I should not treat Yosemite as a cause of storage-related problems of this type.

Invalid Disk Label @ 39341604864: cksum mismatch.

Checksum mismatches may appear to be transient, or not easily reproducible.

Please note: with or without Disk Utility, a run of fsck_cs that completes without a mismatch should not be treated as a guarantee that the storage is good.

Also, when I last checked, Disk Utility could not show S.M.A.R.T. status for drives that use Apple Core Storage.

BrooklynAl said:
little information on check sum errors/disk mislabeling on the web. The Apple senior techs could not provide much help

From the Mac OS X Manual Page for fsck_cs(8):

BUGS

fsck_cs does not perform an exhaustive validation, nor is it able to fix many of the inconsistencies that it does detect.

cksum error resolved

Resolved may be not the best word here. Recall the comment about transience. Note:

an apparent resolution for example, appearance then non-appearance of a checksum mismatch in Disk Utility should not be treated as a guarantee that the storage is good

when Disk Utility states that a volume appears to be OK, you can't be sure that it is completely OK; and so on.

I should recommend a thorough check of affected devices with something more capable than Disk Utility. (For cases such as this, not DiskWarrior.) All affected devices; so if the checksum error affected a Fusion Drive, you should thoroughly check both the hard disk drive and the solid state drive.

For fsck_hfs there's option -S from the manual page:

Cause fsck_hfs to scan the entire device looking for I/O errors. It will attempt to map the blocks with errors to names, similar to the -B option.

You might back up, then start from a different disk (not any Recovery OS on the the affected storage) and use Terminal to initiate a scan of that type. Be prepared for the scan to take a long time much longer than the simple approaches to verification that are offered by Disk Utility.

I have not properly tested option -S I have no idea whether there's more detailed documentation so if you take that approach, proceed with caution and at your own risk.

Ideally

Back up, then set aside plenty of time for an uninterrupted and most thorough check of all affected devices with HDAT2.

If you find that your hardware is not compatible with HDAT2, then aim for something like the extended scan option in Drive Genius and scan the drives, not the volumes.

Related

In Ask Different, the accepted answer to What free or open source software can I use with Mac hardware to verify integrity of every block of a disk where Core Storage is used?

pacmania1982 · Jul 24, 2014

I just combined the partitions as I installed the public beta on a 30GB partition I created earlier.

1) Delete recovery partition, 2) Merge recovery partition and Yosemite partition, 3) Merge main partition with Yosemite partition. (Guide from http://osxdaily.com/2011/06/30/deleting-the-mac-os-x-10-7-lion-recovery-hd-partition/)

Here's what I did:

In Terminal:

Big-Mac:~ rich$ diskutil eraseVolume HFS+ Blank /dev/disk0s3 - Note: This may be a different for you
Started erase on disk0s3 Recovery HD
Unmounting disk
Erasing
Initialized /dev/rdisk0s3 as a 620 MB case-insensitive HFS Plus volume
Mounting disk
Finished erase on disk0s3 Blank
Big-Mac:~ rich$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Big Mac 220.1 GB disk0s2
3: Apple_HFS Blank 650.0 MB disk0s3
4: Apple_HFS Yosemite 29.3 GB disk0s4
Big-Mac:~ rich$ diskutil mergePartitions HFS+ Lion disk0s3 disk0s4
The chosen disk does not support resizing.
Do you wish to format instead? (y/N) y
Merging partitions into a new partition
Start partition: disk0s3 Blank
Finish partition: disk0s4 Yosemite
Started partitioning on disk0
Merging partitions
Waiting for the disks to reappear
Formatting disk0s3 as Mac OS Extended with name Lion
Initialized /dev/rdisk0s3 as a 28 GB case-insensitive HFS Plus volume
Mounting disk
Finished partitioning on disk0
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Big Mac 220.1 GB disk0s2
3: Apple_HFS Lion 30.5 GB disk0s3
Big-Mac:~ rich$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Big Mac 220.1 GB disk0s2
3: Apple_HFS Lion 30.5 GB disk0s3
Big-Mac:~ rich$ diskutil mergePartitions HFS+ BigMac disk0s2 disk0s3
The chosen disk supports resize; disregarding your new file system type and volume name
Merging partitions into a new partition
Start partition: disk0s2 Big Mac
Finish partition: disk0s3 Lion
Started partitioning on disk0
Merging partitions
Waiting for the disks to reappear
Growing disk
Finished partitioning on disk0
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Big Mac 250.7 GB disk0s2

Now I'm just looking for a way to get my recovery partition back in Mavericks!!

***EDIT***

Just found this: http://musings.silvertooth.us/2014/07/recovery-partition-creator-3-8/, so downloading Mavericks from the App Store as we speak.

pacmania1982 · Jul 24, 2014

It worked:

Last login: Thu Jul 24 22:29:42 on console
Big-Mac:~ rich$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Big Mac 250.1 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
Big-Mac:~ rich$

Just rebooted into it to check it, clicked the Install Mac OS X button (or whatever its called) and it came up as Mavericks, so I'm a happy camper again.

Thanks to paladawan for the idea. I've posted what I did for people to follow as you didn't have complete instructions

pac

Kevsta26 · Jul 24, 2014

So just to be sure,

Is it okay to install the Yosemite public beta on my mac which also has a bootcamp partition, or will it mess it up?

Caulin · Jul 24, 2014

Hello. My friend installed Yosemite on a separate partition and everything is exactly as you guys are saying. His had is renamed Yosemite and the Yosemite partition cannot be deleted. Following above instructions when we run diskutil cs list we get a similar image as Brett's. However. The partition we need to change says revertibility: no. Any suggestions?

----------

Kevsta26 said:
So just to be sure,

Is it okay to install the Yosemite public beta on my mac which also has a bootcamp partition, or will it mess it up?

I'm not very knowledgable, however, when I tried to install Linux with boot camp half way through it wouldn't work so I decided to give up. But the partition I made for Linux became free space that couldn't be resized. I had to delete boot camp and reinstall. Apple told me boot camp does not like when you resize the partition

campyguy · Jul 24, 2014

Caulin said:
Hello. My friend installed Yosemite on a separate partition and everything is exactly as you guys are saying. His had is renamed Yosemite and the Yosemite partition cannot be deleted. Following above instructions when we run diskutil cs list we get a similar image as Brett's. However. The partition we need to change says revertibility: no. Any suggestions?

If the Logical Group is not revertible, the next step will be to back up, DL the Install OS of choice, run the installer, use the installer's Disk Utility to erase/partition the subject drive, quit the installer's Disk Utility and install the OS of choice - basically, erase and reinstall the OS of choice (I'd recommend against Yosemite as the main driver - see below...).

As I noted earlier in this thread, as there is no "combo" installer for Yosemite, installing Yosemite could (more like most likely) create a new Logical Group which will then need to be addressed again in Disk Utility. I installed Yosemite on a TB SSD that I partitioned - and was presented with a (revertible) Logical Group, which I reverted. So, take heed of my advice above.

smartalic34 · Jul 24, 2014

Caulin said:
Hello. My friend installed Yosemite on a separate partition and everything is exactly as you guys are saying. His had is renamed Yosemite and the Yosemite partition cannot be deleted. Following above instructions when we run diskutil cs list we get a similar image as Brett's. However. The partition we need to change says revertibility: no. Any suggestions?

If you are still having trouble getting rid of the Yosemite partition (and if that's what you want to do), here is a much easier way to do it, and avoids the Terminal completely:

1) Reboot the computer - when the screen turns black on the restart, hold down Command and R
2) This will boot you into the Recovery partition - select Disk Utility (note, this is a different Disk Utility from the one in the user's Utilities folder)
3) Select the Yosemite partition, go to the Erase tab, and click Erase
4) You can now click on the partition to delete it
5) Drag the main partition so that it refills the entire space of the disk

The Recovery partition Disk Utility has different permissions (or something to that effect) that allows it to override the Logical Group. This leaves the other partition untouched.

Caulin · Jul 24, 2014

I cannot do that. It will not let me delete the Yosemite. However I can delete the original partition named Macintosh hd. When I click on the Yosemite partition I cannot click plus or minus

Apple_Robert · Jul 24, 2014

Caulin said:
I cannot do that. It will not let me delete the Yosemite. However I can delete the original partition named Macintosh hd. When I click on the Yosemite partition I cannot click plus or minus

You can't delete a core HD partition, which is how Yosemite was set up by default. There is a very simple way to covert the partition that takes a matter of 2 minutes or less in the terminal using two commands, but I don't have them memorized.

Weasel Boy or someone else may know the thread and post I am referring to. I had the same problem with DP1 and the fix worked like a charm.

Caulin · Jul 24, 2014

Those two commands are in this thread I believe.

Caution - Yosemite may screw up partitions.

macrumors 68040

Contributor

macrumors regular

macrumors newbie

macrumors 6502a

macrumors 6502a

macrumors Haswell

macrumors 6502

macrumors 6502a

macrumors regular

macrumors 6502a

macrumors regular

macrumors 68000

macrumors 68030

macrumors 68040

macrumors 601

macrumors 65816

macrumors 65816

macrumors 6502a

macrumors newbie

macrumors 68040

macrumors 6502a

macrumors newbie

Attachments

Contributor

macrumors newbie

Our Staff