I have an SSD (disk0
) that contains my macOS Mojave installation. SIP is enabled (and for reasons outside my control, cannot be disabled) so I cannot give the output for gpt -r show disk0
nor can I unmount disk0
.
But going into Windows (installed on a completely separate drive), is one partition located at the end of the drive (my macOS install) with free space preceding it but I was unable to run diskutil apfs resizeContainer disk0s3 0
because of Error: -69743: The new size must be different than the existing size
.
I tried creating an APFS partition and merging the two together, after creating a partition, this is what the diskutil list disk0
output is:
/dev/disk0 (external):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 250.1 GB disk0
1: EFI SYSTEM 536.9 MB disk0s1
2: Apple_APFS Container disk5 110.0 GB disk0s2
3: Apple_APFS Container disk1 139.5 GB disk0s3
Running diskutil mergePartitions APFS Macintosh disk0s2 disk0s3
gives me
You cannot merge disks into an APFS Physical Store
Instead, you can delete the partitions following the APFS Physical Store by
using "diskutil eraseVolume free n <disk>" for all such partitions, and
then by growing the corresponding APFS Container by its APFS Physical Store
to fill the gap by using "diskutil apfs resizeContainer disk0s2 0"
Doing so in the reverse order gives me
The given partitions are not ordered sequentially on disk
The only problem is, they are sequential!
I don't want disk0s2
because that is my free space, I need to preserve disk0s3
. GParted's APFS support is limited so I'm hesitant with shifting the APFS drive using that. All resizing guides presume free space is succeeding the partition, what should be done if it is preceding the partition?
Best Answer
I copy the contents of the container to a new disk / volume and then evaluate if it's faster to erase the entire drive or I want to merge / rearrange things.
The short answer is the tools are designed to have one container for the entire storage so you can move date between volumes without running into ordering issues. One container per drive is how I run boot volumes to avoid painting myself into a corner like you have done here.
The long answer is use volumes inside a container so you're working on a synthesized disk as opposed to a physical disk.
So, in your case, here is what a machine might look like as you prepare to upgrade to Big Sur where you can maintain a Catalina / Mojave and Big Sur beta Volume alongside the Big Sur shipping version when it's time to upgrade Macintosh HD to Big Sur.
Also, now that I said you can't do it - can you shrink the files on disk0s3 so that it fits in disk0s2 / move the data, then delete disk0s3 and grow disk0s2 to consume the now free space at the end of the physical disk?