Expand old JHFS+ disk on the command line
For a test I partitioned an external 500GB disk with a 157.3GB JHFS+ partition and the remaining 342.8GB with an Linux ext2. The whole thing was meant as backup disk. After some cleanup I was able to move all the data from the ext2 partition off somewhere else. Eventually I wanted to make resize the JHFS+ partition to use all the 500GB. I thought that would be fairly simple. But I was totally wrong and had to really work hard to make it work. The description here is how I eventually got it working navigating around all the issues along the way.
Repartion an disk that was created on an older version of MacOS X to use 100% of the disk space. Important the data on the volume must stay intact.
- diskutil (MacOS X)
- parted (Linux)
There were a few issues along the way that had to be addressed one by one. Each is described in a subsection sequentially.
Starting out on the Mac diskutil list showed the following output.
Note: The disk is using an MBR or in Mac-speak FDisk_partition.
# diskutil list /dev/disk1 #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *500.1 GB disk1 1: Apple_HFS backup 157.3 GB disk1s1 2: Apple_HFS disk1s2 342.8 GB disk1s2
Wrong partition scheme
Being fairly unfamiliar with the Mac tools I found diskutil has a number of great tools such as mergePartitions or resizeVolume unfortunately running them resulted in an rather non descriptive error.
# diskutil mergePartitions JHFS+ backup disk1s1 disk1s2 Merging partitions into a new partition Start partition: disk1s1 backup Finish partition: disk1s2 disk1s2 Merging partitions encountered error "MediaKit reports partition (map) too small (-5341)". The erase will not occur.
I was under the impression that the max partition size for MBR was 2TB but maybe it is different on the Mac so I wanted to convert it to GPT. And the almighty Internet could not clear thing up for me. In hindsight I was wrong all along and could have saved me some time but to that later.
Trying to resize the volume was not much better. The R is to use all the available space.
# diskutil resizeVolume /Volumes/backup R Error obtaining resizing information for grow to maximum
At this point I decided to convert the whole disk to GPT. However doing so will destroy all data unless after the disk has been relabeled the exact same partition is put back in place. When it comes to partitioning making mistakes can send all the data south. As such I did it with the tool and OS im most familiar, parted on Linux had to do the repartitioning.
Recreate the partition table under GPT in Linux
To be ultra precise the unit of the display is set to Bytes. The print then shows the partition information prior to making any changes.
# parted /dev/sdX (parted) unit B (parted) print Model: BUFFALO HD-PEU2 (scsi) Disk /dev/sdc: 500107862016B Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32256B 157283804159B 157283771904B primary hfs+ 2 157283804160B 500105249279B 342821445120B primary hfs+ boot
With that information available the next step is to relabel the disk to GPT.
(parted) mklabel gpt Warning: The existing disk label on /dev/sdc will be destroyed and all data on this disk will be lost. Do you want to continue? Yes/No? y
At this point the disk has lost the previous partition table. In the next step we put it back exactly at the same boundaries as they were before. As the second partion is no longer used only the one holding the data is recreated.
(parted) mkpart Partition name? ? Apple_HFS File system type? [ext2]? HFS Start? 32256B End? 157283804159B Warning: The resulting partition is not properly aligned for best performance. Ignore/Cancel? i (parted) quit
With that connecting the disk back at the Mac.
Resizing with the GPT partition scheme
Back on the Mac diskutil list shows that the new partition scheme is in place and the data is miraculously still around.
# diskutil list /dev/disk1 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.1 GB disk1 1: Apple_HFS backup 157.3 GB disk1s1
Now with another resizeVolume attempt things look a lot better. This command takes a long time to go through all the checks so be patient.
Note: I was using 100% first which is not working at all. One must use R instead or it will bomb.
# diskutil resizeVolume disk1s1 R Started partitioning on disk1s1 backup Verifying the disk Checking file system Checking Journaled HFS Plus volume Checking extents overflow file Checking catalog file Checking multi-linked files Checking catalog hierarchy Checking extended attributes file Checking multi-linked directories Checking volume bitmap Checking volume information The volume backup appears to be OK Resizing Finished partitioning on disk1s1 backup /dev/disk1 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.1 GB disk1 1: Apple_HFS backup 500.0 GB disk1s1