6

I'm trying to use entire 1TB HD as 1 drive. Using the disk utility to resize the disk to 1TB I keep getting "The New size must be different than the existing size". I tried using the apple disk utility but got the same thing.

ADDITIONAL INFO I forgot to mention... I did clone a drive that was 256GB on to this 1TB drive... Then I ran the disk utility to repair it.

screenshot

3
  • You should have a EFI partition at disk0s1. Can you edt the results of sudo gpt -r show disk0 into your question. – lx07 Nov 14 '19 at 8:24
  • I get gpt show: unable to open device 'disk0': Operation not permitted – pew pew Nov 15 '19 at 3:35
  • Sorry, I forgot to mention that you need to disable SIP to use sudo gpt -r show disk0 for your boot disk. It is worth doing as it will confirm where on the disk your partition is. – lx07 Nov 15 '19 at 7:38
13

This helped me:

  1. repair (internal, disk0 - in your case)

    diskutil repairdisk disk0

  2. resize (synthesized, disk1 - in your case with HS)

    diskutil apfs resizeContainer disk1 0

After repairdisk resizeContainer works with no errors. You can see a similar issue over here for more context: Cannot resize APFS partition - "The new size must be different than the existing size"

4
  • Welcome to Ask Different. Does the repair disk have a chance to delete data? – bmike May 10 '20 at 14:44
  • repairdisk warned me about possible affect on EFI partition, so I did backup. But in my case i didn't lost any data. – Ilya K May 10 '20 at 15:24
  • Thanks. I worry some of these cases are really delicate up when klanomath and David Anderson are picking apart machines one command away from losing everything and someone will run repair and lose their last chance to fix their partition table and allocation size information that they are hand editing. Repair makes the accounting sane again, at the expense of losing data in my experience. – bmike May 10 '20 at 15:36
  • Worked for me, thanks ! – Entretoize Sep 16 '20 at 16:45
2

This error message occurs when there is little or no free space directly below the APFS container you are trying to enlarge. For example, below is the diskutil list disk2 output of a disk image where virtually all the free space has been allocated to partitions.

/dev/disk2 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS tbd                     749.9 GB   disk2s2
   3:                 Apple_APFS Container disk3         249.8 GB   disk2s3

One can see 209.7 MB + 749.9 GB + 249.8 GB = 1.000 TB. If the following commands are entered, then disk2s1 and disk2s2 will be converted to free space.

diskutil erasevolume free none disk2s1
diskutil erasevolume free none disk2s2

The resulting output from diskutil list disk2, after entering the above commands, is shown below.

/dev/disk2 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +1.0 TB     disk2
   1:                 Apple_APFS Container disk3         249.8 GB   disk2s3

The command given below can be used to return free space directly below a apfs partition to the enclosed apfs container.

diskutil apfs resizeContainer disk2s3 0 

However, since all significant free space is above the partition, the following error message is generated.

Started APFS operation
Error: -69743: The new size must be different than the existing size

The exact position and size of the disk2s3 partition can be determined by entering the following command.

diskutil info disk2s3 | grep -e Offset -e Size

In this case, the command produces the following output.

   Partition Offset:         750209736704 Bytes (1465253392 512-Byte-Device-Blocks)
   Disk Size:                249.8 GB (249790263296 Bytes) (exactly 487871608 512-Byte-Units)
   Device Block Size:        512 Bytes

The following sum results in the ending position of the disk2s3 partition.

750,209,736,704 bytes 249,790,263,296 bytes  = 1,000,000,000,000 bytes = 1.000 TB

One can see the there is no appreciable free space after the disk2s3 partition, which is why the error message appeared.

The exact size of the disk image can be determined by entering the following command

diskutil info disk2 | grep Size

In this case, the output is shown below.

   Disk Size:                1.0 TB (1000000020480 Bytes) (exactly 1953125040 512-Byte-Units)
   Device Block Size:        512 Bytes

This shows 20480 bytes of space exists after the end of the disk2s3 partition. However, not all of this is free space. Part of this space is occupied by the backup copy of the GUID partition table (GPT).

Since this is a disk image, the following command can be entered without having to disable System Integrity Protection (SIP).

gpt -r show /dev/disk2

In this case, the command produces the following output.

       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34  1465253358         
  1465253392   487871608      1  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  1953125000           7         
  1953125007          32         Sec GPT table
  1953125039           1         Sec GPT header

This output shows there are actually 7 sectors of free space after the disk2s3 partition. Since the sector size (device block size) is 512 bytes, the free space computes to 3,584 bytes. This is smaller than the 4096 byte allocation block size required for the diskutil apfs resizeContainer disk2s3 0 command to proceed.

Presently, the allocation block size for APFS is fixed at 4096 bytes. In this case, the allocation block size can be confirmed by entering the command given below.

diskutil info disk3s1 | grep Allocation

The output from this command is shown below.

   Allocation Block Size:    4096 Bytes
7
  • Are you suggesting that the OP had one 750GB partition before disk0s2 and that after deleting/losing it find disk0s2 is the only partition left and it is right at the end of the disk? I'd suggest this is unlikely and it is more likely that EFI was the first partition and there is free space after but results of gpt -r show or similar are needed. Surely if they deleted EFI and another earlier partition you would see disk0s3 as the remaining partition (as in your test) not disk0s2. – lx07 Nov 14 '19 at 15:43
  • @lx07: The disk identifiers are not linked to the partitions indices. You assume disk0s3 in my example is the third partition in the GPT. While this is true at the start of my example, you can see from the output of the gpt -r show /dev/disk2 command that disk0s3 is the first partition in the GPT at the end of the example. You also can not always assume the partitions in the GPT are in ascending order. Although, if the diskutil command changes the GPT, the result will be partitions in ascending order. – David Anderson Nov 14 '19 at 15:58
  • @lx07: Honestly, I assume the OP restarted the Mac as some point. This would reassign the disk identifiers. This would be one way to account for the identifier being disk0s2 instead of disk0s3. In other words, the OP restarted the Mac before entering the command diskutil erasevolume free none disk0s1, then posted the question. BTW, you do not have to disable SIP and use the gpt command to get the partition table. You can get the table by using the diskutil command or download a script that will. – David Anderson Nov 14 '19 at 16:13
  • 1
    @lx07 The OP probably deleted disk0s2 (some 750 GB partition) much earlier and rebooted. In the next step the OP successfully deleted the EFI partition (disk0s1) (no traces in the screenshot but probably hidden further up in the Terminal window - a pity, that we can't scroll in the screenshot here) and failed to delete disk0s00 and disk0s0 (which is shown in the screenshot). – klanomath Nov 14 '19 at 17:27
  • @klanomath: I do not have an exact answer. The script will work if the diskutil command will output the partition offset information. I know this happens with High Sierra and newer versions of macOS, but I am not sure which version of macOS (OS X) where this started. If the diskutil command does not produce the needed output, the script will produce an error message. This is why the man page shows High Sierra and newer versions of macOS. – David Anderson Nov 14 '19 at 18:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .