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.

Task

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.

Tools

• diskutil (MacOS X)
• parted (Linux)

Howto

There were a few issues along the way that had to be addressed one by one. Each is described in a subsection sequentially.

Starting point

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

Note: Before starting copy the partition table of the disk to a text file so that it can recovery is possible should things turn pear shaped.

Any mistake in this process can destroy you data. Do not just copy and paste the example data here. If you are unsure and you don't have a backup of your data don't blame me.

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

Yeah!!