I highly recommend completely backing up the machine before attempting this, either using TM with no exclusions set, or better yet, cloning the whole drive using a program like Carbon Copy Cloner.
Unmount the Logical Volume:
sudo diskutil unmount force /dev/disk1
Remove the Logical Volume Group and all of its contents:
sudo diskutil cs deleteLVG B6308EC8-297D-44BD-9212-6BD867F6331B
From diskutil's man page:
delete | deleteLVG lvgUUID | lvgName
Delete a CoreStorage logical volume group. All logical volume families with their
logical volumes are removed, the logical volume group is destroyed, and the now-
orphaned physical volumes are erased and partition-typed as Journaled HFS+.
Merge the now orphaned partition disk0s4
into startup volume disk0s2
(note: disk0s3
, one recovery partition, will be erased and merged as well). disk0s5
, the other recovery partition, shouldn't be affected:
sudo diskutil mergePartitions HFS+ "Apple_HFS Macintosh HD" disk0s2 disk0s4
Again, from the man pages:
Merge two or more partitions on a disk. All data on merged partitions other than the first
will be lost. Data on the first partition will be lost as well if the force argument is
given.
If force is not given, and the first partition has a resizable file system (e.g. JHFS+), the
file system will be preserved and grown in a data-preserving manner; your format and name
parameters are ignored in this case.
Verify the boot Volume structure.
diskUtil VerifyVolume /
Verify the partition map:
diskutil verifyDisk disk0
Boot into Recovery Mode, or Internet Recovery if needed -- if any errors appear:
You should be left with:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *320.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 319.7 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
If you want better answers, try refining your question. Also, post a comment after my answer, so I will be notified.
Question:
1) Recovery HD is visible, which, I could be mistaken, but this shouldn't be visible OR mounted in Disk Utility
Answer:
In the MBR partition table, the id should be AB
and you have AF
. In the GPT, the partition type should be 426F6F74-0000-11AA-AA11-00306543ECAC
and you have48465300-0000-11AA-AA11-00306543ECAC
. This is why it is visible.
Question:
2) disk0s4 is actually ext4, NOT JHFS+.
Answer:
You used the gdisk
to change the partition type code for disk0s4 from AF00
to 8300
while disk0s4 while it was still mounted. The Disk Utility application will not see the change until you unmount and mount disk0s4.
Question:
where is disk0s5
Answer:
Currently, the fifth entry in the GPT is not being used. You have not given any information regarding the values in this table entry, other than due to its absence the partition type must be 00000000-0000-0000-0000-000000000000
. For all anyone knows, the UUID, attributes, label and starting/ending sector numbers may still be stored in the fifth table entry.
Note: I have observed the Disk Utility application requires the entries in the GPT to be in ascending order and contiguous. The output of the gpt
command shows the indices to be in ascending order, but since the fifth entry is missing, the indices are not contiguous. When a situation like this occurs, the Disk Utility application can incorrectly display the contents of the GPT. In your case, the errors shown by the Disk Utility application where most likely caused by the use of gdisk
.
Why did you use a BIOS/MBR install of Ubuntu? I know you can download such an iso, but the EFI/GPT iso version also works on Mac's. This is what I choose for my mid 2007 20-inch iMac. This way you can avoid using a hybrid GPT.
Best Answer
Starting from a working setup
A working setup is disk, or full-disk image with multiple partitions (FDI hereafter), where the OS and its recovery partition is known to be correct, most likely because it was created by the OS Installer. As mentioned in the comment,
asr
is enough to handle copying both partitions in this case.Assuming the source OS and recovery partitions are
disk3s11
anddisk3s12
, respectively, I recommend the following procedure:Shrink the OS partition to its minimum size. This isn't necessary, but I suggest doing it when you can never be sure if the user's target partition will be as big as the one you're using.
Create appropriately-sized temporary FDI as a sparsebundle. Remember, the Recovery takes extra 650 MB over the system partition, and EFI takes another 210 MB. So I'll add an extra GB to the size used in step 1 just to be safe. The catch here is,
hdiudil
support only binary prefixes (1024 fork
, etc.). In this example, 25 GB = 23.29 GiB.Attach the image without mounting it (it would fail, since the partition was not formatted). Take note of the
/dev/
entry for the Apple_HFS partition.Run
asr
with the image's empty partition as the target. You'll have to enter full path to/dev/...
entries. Also, since the source is a physical disk, elevated privileges are necessary. You should see the tool finish with 2 rows of Restoring... progress.Finally, create a compressed read-only image from the sparsebundle. Use the sparsebundle's "whole disk"
/dev/
entry (/dev/disk5
).You may wish to use
UDZO
format if you need your image to be compatible with older versions of OS X and their respective Recovery environments (ULFO was only introduced in 10.11).Working from the ground up
It is possible to assemble a "working setup" from single-partition images (images which don't have partition table, and therefore no hint for
asr
that a particular partition is a Recovery; SPI hereafter). The procedure is not for the faint of heart.I'm going to assume that I have a compressed, read-only SPIs of both the system partition, and the recovery partition. Shrinking the partitions to minimum size is a whole another can of worms, where using a full-blown
UDRW
image seems unavoidable. Feel free to suggest a simpler solution.With that in mind, do a pre-shrink of the system partition image. Readonly image can only be shrunk with a shadow.
Check the image size, then attach it
The size is about 27.65 GB.
Create a sparse image big enough to hold the system and recovery partitions in full size - AFAICT, SPIs cannot be resized and that must be done inside an FDI. With extra space needed for EFI and recovery, we'll need 28.6 GB = 26.64 GiB.
Do an
asr
restore from the system SPI's/dev/
node into the sparsebundle's data partition.Now, check the minimum size of the partition using
diskutil
. Then useresizeVolume
to shrink the partition and create the recovery partition in a single step.Restore the recovery SPI into the new partition on the FDI. It will probably get mounted, so unmount it. You can work with the image directly.
Here's the tricky bit - dump the partition table using the
gpt
utility, taking note of the recovery partition's start and size values. Delete the record for the recovery partition, and re-add it with modified type GUID. You will know which record is for the recovery partition by the index ("disk5s3"), and by its size (shown here in 512 B sectors).Optional: I also recommend changing the partition name (set to "disk image" by default) to match the system partition's volume name.
Now, since
hdiutil resize
doesn't work with sparsebundles the way we'd need, you can either:asr
, which will this time copy both partitions into the new image, and convert that to ULFO image.Restoring
Steps for restoring from the created image:
Mount the image using
Start the restore, either by:
Use
asr
, similarly as described above:$ asr restore --source /dev/disk1s2 --target /dev/disk0s4 --erase --noverify