windows 8 does not recognise Macintosh HD, No drive Letter

That's good news. In my case Windows was installed after-the-fact. And the 10.10 install I did was an upgrade, not clean. So it'd be good to know what behavior we get with clean installs, because the all too common message from Boot Camp Assistant is to erase the drive creating a single partition. If such clean installations cause a CSLV to be created, then anyone installing Windows after 10.10 is in for a significant limitation in functionality.

The Core Storage documentation is limited, but descriptions include that it uses COW (copy on write). I don't know if it always does this, or if only in the case of Fusion drives. But it would make things more reliable if it's always employed, the idea is that even if HFS+ thinks it's overwriting a file, those writes are directed to new physical extents by CoreStorage instead of the old ones. If the transaction is completed (thus successful) then CS can map the logical extents to the new physical extents, and release the old ones. If the transaction fails, then the old data is completely intact rather than having been overwritten or partially overwritten and thus corrupt. So... it might be better. But the lack of details lends only to speculation.

I can find http://eprint.iacr.org/2012/374.pdffrom http://askubuntu.com/questions/272351/how-to-mount-apple-core-storage-partition

The white paper is well written.

So I'm finding that Boot Camp Assistant is resizing the filesystem, the LV, the LVG, the PV, and the partition - and migrating Recovery HD - anytime a "boot camp volume" is created or destroyed. This is very different from before. And even while this is happening, ps aux is not revealing what's running to do this work. It doesn't seem to be diskutil. And even looking at the man page for diskutil I don't see any diskutil cs commands that can do what's being done, i.e. there is no diskutil cs resize command. If I run 'diskutil resizevolume <dev> limits' on either the partition/PV or the LV/HFS+ volume, I get an error: Error obtaining resizing information: disk is a Core Storage Logical Volume; or Volume format does not support resizing. So I'm kinda stuck how to do any resizes outside of Boot Camp Assistant.

Further, in Disk Utility, when I have a BOOT CAMP volume, it prevents any changes other than flat out deleting the BOOT CAMP volume. It appears no longer possible to resize the OS X volume. I don't know yet if that's due to it being a Core Storage Logical Volume or if it's downright prohibited, which is probably wise considering all the problems we've seen when users do this.

Looks like diskmanagementd is doing this work on behalf of Boot Camp Assistant and Disk Utility. It has no CLI. And it looks like it uses DiskManagement.framework.

I wish the diskutil man page would document these.

The following phrase is very interesting...

"Unable to run because unable to use the DiskManagement framework.

Common reasons include, but are not limited to, the DiskArbitration

framework being unavailable due to being booted in single-user mode."

Here are some pieces...

info

convert

revert

createLVG

delete

deleteLVG

addDisk

addPV

removeDisk

removePV

createVolume

createLV

deleteVolume

deleteLV

encryptVolume

encryptLV

decryptVolume

decryptLV

unlockVolume

unlockLV

changeVolumePassphrase

passwd

resizeVolume

resizeLV

resizeDisk

resizePV

resizeStack

I ran strings on diskutil binary, and see these functions...

Usage: diskutil coreStorage resizeDisk pvUUID size

Resize a physical volume, which is one of one or more disks that provide storage

to a logical volume group. The logical volume group will have less or more

available space after this operation, if it was a shrink or grow, respectively.

be created in the newly-formed free space gap.

Example: diskutil coreStorage resizeDisk

Usage: diskutil coreStorage resizeStack

lvUUID|MountPoint|DiskIdentifier|DeviceNode [pvUUID] size

[part1Format part1Name part1Size part2Format part2Name part2Size

part3Format part3Name part3Size ...]

Resize both a logical volume and one of its underlying physical volumes in a

single operation. A single physical volume is always chosen for the underlying

shrink or grow, even if the logical volume's logical volume group is backed by

more than one physical volume. If you do not specify a particular physical

volume, then one is chosen for you. Note that if this is a grow operation,

this verb is limited by the physical volume's partition's room to grow.

Specifying zero as the size asks for an "automatic" grow-to-fill operation.

If this is a shrink operation, you can optionally request that new partitions

be created in the newly-formed free space gap in the partition map.

Again, note that this only resizes one of the underlying physical volumes; if

you need more sophistication in managing your topology, you should use the

separate physical and logical volume resize verbs.

Example: diskutil coreStorage resizeStack

11111111-2222-3333-4444-555555555555 10g JHFS+ New 1g

I've got a test machine that can be obliterated. So I tested this. I started out with a single OS X volume which is a CSLV. This is the command used:

diskutil cs resizestack disk1 250G "MS-DOS FAT32" DOG 248G

disk1= the LV

250G = the size I want the LV to be

"MS-DOS FAT32" I had to put in quotes because it doesn't understand spaces

DOG is the name of the new volume being created in resulting free space, and it had to be all caps or I get an error

248G is the size of the new volume

A summary is:

fsck

shrink filesystem

shrink LV

resize PV

resize partition

"copying booter" which I think is moving Recovery HD, which is in fact moved [1]

update partition map (includes GPT and creating hybrid MBR in this case, apparently inferred because of the MS-DOS choice)

format the new partition as FAT32

At the end it looks indistinguishable from what BCA would do, and BCA even considers it something it can remove and restore things back they way they were.

To reverse this by CLI is a two step process, as resizestack doesn't include destroying another volume.

diskutil erasevolume "Free Space" %noformat% disk0s5

Next I run into a bug I think "Specifying zero as the size asks for an "automatic" gro-to-fill operation." But I get an error whether I use size 0 or zero. So I end up using:

diskutil cs resizestack disk1 498G

Summary of events:

fsck

grow PV

copy booter

update partition map

grow LV

grow filesystem

gdisk says I've got 836MB free/unallocated space on the disk. So I've lost just under 1GiB with the manual shrink/grow routine, because I don't seem to have a wildcard to indicate "grow to fill".

AHA! Instead of 0 for size, I just used 0g and that worked. Now I have only 6.5KiB free/unallocated.

[1] why? why not just make this partition 2 and never have to move it? everyone else does it this way and it's much simpler and safer than copying it around each time. weirdness.

Thanks for testing this, Christopher. I did not have a test machine handy to test.

I agree, moving partitions, especially large ones, is opening a door to disaster. Moving data on disk should be minimized. The current BCA movement is alsocausing too much pain for existing BC users.

There are two posters who have iMac5K Retinas with Fusion drives, and have issues with BC that I am trying to assist.

Hopefully the next update to Yosemite can address some of these issues.

Where did you get back the Mavericks installation package? it is no longer in the AppStore...

Thanks in advance,

Regards

Loner T wrote:

Yosemite logical volumes cannot be read on Windows bootcamp anymore since they are not HFS+ volumes but they are now CoreStorage. Till Bootcamp is updated with drivers to allow read access to CoreStorage HFS+, you have lost functionality by upgrading to Yosemite. 😟.

You can verify this on the OS X side by running diskutil cs list in OS X terminal. If it returns any output, Windows cannot read such volumes.

It's true that Yosemite switched to Logical Volumes (CoreStorage)
BUT IT'S NOT TRUE THAT YOU CANNOT FIX IT AND RESTORE YOUR ACCESS TO THE PARTITION ALSO FROM WINDOWS BOOTCAMP

You can revert the partition to native HFS+ and access it from windows bootcamp in 1 minute, i just did it:

I understood it afert reading this thread for another issue but the cause is the same: http://apple.stackexchange.com/questions/134498/unable-to-resize-partitions

TO BE ABLE TO ACCESS YOUR HFS+ from windows do the folliwing

1) Boot in Mac OS Yosemite
2) Open terminal

3) sudo su

4)

diskutil corestorage list

Reboot in windows, and now enjoy YOUR data

PS. I'm really disappointed with yosemite, overheating and eating my NON-UPGRADABLE 16GB RAM of my 3300,00+ € MacBook Pro Retina '13.
Ram usage is at 70% just when i boot it, and 100% and swapping like crazy just with chrome and a pair tabs open, CPU over 100°C just when i open chrome browser and so some browsing (I think this is due to non-smart handling of i7 speedstep/turbo mode by the OSX). In windows bootcamp instead I've an usage of just 2GB at boot and 4-5GB RAM when I've all my apps open (huge apps, photoshop, chrome with hundreds of tabs and heavy netbeans ide with big projects inside).
If you are experiencing slowness and overheating with your Macbook Pro Retina, I suggest you to disable i7 turbo mode guys, it's the main source of overheating and slowness (slowness due to throttling of cpu and kernel_task going crazy, constantly enabling turbo mode cause it feels slow and disabling it for overheating). In windows you can do fine and extend your Macbook lifetime by setting CPU energy saving profile to a max of 99% of cpu frequency. This will disable turbo mode and set it at the native operating frequency -1%.

If this yosemite upgrade was a way to ask me to buy a new macbook you failed. I already was knowing that the price for the hardware you sell is too high, but I accepted it because I liked the OS, that was awesome until Steve was in life. But now that the OS is s***ing and destroying the hardware.. I think that I'll not buy a mac next time

Reverting is allowed only if the CS volume is revertible, and you do not have a Fusion drive. Your solution does not work for everyone, but only single-disk CS volume Macs on Yosemite. The proper solution is for Apple to provide a CS driver for Windows, the way it is done for HFS+.

The other option is to look for third-party solutions from Tuxera, NTFS-3g and Paragon, or others.

Hi Loner T, it will work for any Macbook Pro Retina User.

And who opened this thread is one of them:

MacBook Pro (Retina, 13-inch, Late 2013), OS X Yosemite (10.10)

P.S. ParagonHFS+ also wasn't able to find the logical volume so I think my solution will help a lot of Macbook Pro Retina users that have my same issue as for now is the only solution.

After reverting i'm also able to read/write the partition with paragon HFS+, but before the system wasn't able to mount the drive at all

Your little code allows me to access OS X part files and folders while I am in Windows 8.1 part. Awesome! You have saved my life dude!