Disk Utility – Fix Windows EFI Partition Deletion Issue

disk-utilityefihard drivepartitionstartup

I am trying to multiboot Windows, Linux and macOS Catalina all installed on the same drive. I can get it working quite easily if macOS is the first OS on the drive.

However I have problems if my drive partition layout is like this:

Windows EFI
Windows OS
Linux Root
Linux Home
macOS EFI
macOS
exFAT share partition

I read that it is safer to format an exFAT partition from macOS disk Utility if that partition is to be used to share data between macOS and other OSs.

So I repartitioned the "share partition" in macOS disk utility to format it again as exFAT. But when I did this my Windows EFI partition was deleted and I can no longer boot in to Windows or Linux.

I know how to rebuild the Win 10 boot files and Grub bootloader config and I also know what I am doing is not good practice.

I am only asking what is going on such that a simply change to a drive partiton in Disk Utility causes the Windows EFI partition to become deleted? This didn't happen on my other multiboot set up when the macOS EFI partition is the first partition on the drive followed my macOS then Windows EFI/WindowsOS/LinuxOS.

From testing the same thing happens when I use disk utility to clone a macOS installation into a container on a drive that already has Windows on it… the Windows EFI gets nuked.

Cheers,

Flex

Best Answer

I do not understand your justification for having two EFI partitions. Since you have stated both Windows and Linux are using the first EFI partition to boot, then there is no reason for having the second EFI partition. Most likely if you eliminated the second EFI partition, then the Disk Utility would not be deleting the first EFI partition.

Both the Disk Utility application and diskutil command are complex software developed by Apple to simplify the most disk management tasks. (Here a disk could be a HDD, SSD, USB drive, image file such as .dmg or .sparseimage, image folder such as .sparsebundle, etc...) Using either is a learned experience. In your case, you learned something the Disk Utility application can not do as expected. Or, can not do as expected with your version of macOS. I suppose in the future you should avoid this problem by using newfs_exfat command instead.

Update Regarding Your Triple Boot

When the Boot Camp Assistant is used to install UEFI booting Windows for a dual boot arrangement, the existing EFI partition is used for the Windows boot files. This EFI partition is 209.7 MB (409,600 sectors) when the sector size is 512 bytes and 314.6 MB (76,800 sectors) when the sector size is 4096 bytes. Since you are also installing an UEFI booting Linux and have a sector size of 512 bytes, an EFI partition of around 300 MB should be sufficient. I feel an increase to 300 MB is more that enough, since the boot files in the EFI partition for Ubuntu on my iMac only use about 9.8 MB.

Update Regarding the Behavior of Disk Utility and `diskutil`

Below is the diskutil list disk1 output from a disk image. If you do not know, a disk image is a file or folder which can be mounted as drive.

$ diskutil list disk1
/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +4.0 GB     disk1
   1:                        EFI EFI                     104.9 MB   disk1s1
   2:                        EFI EFI                     209.7 MB   disk1s2
   3:       Microsoft Basic Data MYFAT32                 3.7 GB     disk1s3

If I try to use the Disk Utility to format disk0s3 as ExFAT, I will get the following error message. I have learned this is caused by the first EFI partition being to small.

If the diskutil command is used to format disk1s3 as ExFAT, a similar message appears, as shown below.

$ diskutil erasevolume exfat MyExFAT disk1s3
Started erase on disk1s3 MYFAT32
Unmounting disk
Error: -5344: MediaKit reports not enough space on device for requested operation

Next, the first EFI partition is removed, as shown below.

$ diskutil erasevolume free none disk1s1
Started erase on disk1s1 EFI
Unmounting disk
Finished erase on disk1
$ diskutil list disk1
/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +4.0 GB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s2
   2:       Microsoft Basic Data MYFAT32                 3.7 GB     disk1s3

Now the Disk Utility works, as shown below. Since first EFI partition is now large enough, the operation succeeds.

If the same also succeeds with using the diskutil command, as shown below.

$ diskutil erasevolume exfat MyExFAT disk1s3
Started erase on disk1s3 MyExFAT
Unmounting disk
Erasing
Volume name      : MyExFAT
Partition offset : 614440 sectors (314593280 bytes)
Volume size      : 7198067 sectors (3685410304 bytes)
Bytes per sector : 512
Bytes per cluster: 32768
FAT offset       : 128 sectors (65536 bytes)
# FAT sectors    : 896
Number of FATs   : 1
Cluster offset   : 1024 sectors (524288 bytes)
# Clusters       : 112453
Volume Serial #  : 61a3d821
Bitmap start     : 2
Bitmap file size : 14057
Upcase start     : 3
Upcase file size : 5836
Root start       : 4
Mounting disk
Finished erase on disk1s3 MyExFAT
$ diskutil list disk1
/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +4.0 GB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s2
   2:       Microsoft Basic Data MyExFAT                 3.7 GB     disk1s3

Next, the remaining EFI partition is removed, as shown below.

$ diskutil erasevolume free none disk1s2
Started erase on disk1s2 EFI
Unmounting disk
Finished erase on disk1
$ diskutil list disk1
/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +4.0 GB     disk1
   1:       Microsoft Basic Data MyExFAT                 3.7 GB     disk1s3

Now, there are no EFI partitions. One would expect both the Disk Utility and diskutil to fail when trying to format this last partition. However both succeed, as shown below.

Note, the output below shows the Disk Utility also created a new EFI partition.

$ diskutil list disk1
/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +4.0 GB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:       Microsoft Basic Data MyExFAT                 3.7 GB     disk1s3

Before trying the diskutil erasevolume exfat MyExFAT disk1s3 command, this new EFI partition is removed, as shown below.

$ diskutil list disk1
/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +4.0 GB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:       Microsoft Basic Data MyExFAT                 3.7 GB     disk1s3
$ diskutil erasevolume free none disk1s1
Started erase on disk1s1 EFI
Unmounting disk
Finished erase on disk1
$ diskutil list disk1
/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +4.0 GB     disk1
   1:       Microsoft Basic Data MyExFAT                 3.7 GB     disk1s3
$ diskutil erasevolume exfat MyExFAT disk1s3
Started erase on disk1s3 MyExFAT
Unmounting disk
Erasing
Volume name      : MyExFAT
Partition offset : 614440 sectors (314593280 bytes)
Volume size      : 7198067 sectors (3685410304 bytes)
Bytes per sector : 512
Bytes per cluster: 32768
FAT offset       : 128 sectors (65536 bytes)
# FAT sectors    : 896
Number of FATs   : 1
Cluster offset   : 1024 sectors (524288 bytes)
# Clusters       : 112453
Volume Serial #  : 61a3ea2c
Bitmap start     : 2
Bitmap file size : 14057
Upcase start     : 3
Upcase file size : 5836
Root start       : 4
Mounting disk
Finished erase on disk1s3 MyExFAT
$ diskutil list disk1
/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +4.0 GB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:       Microsoft Basic Data MyExFAT                 3.7 GB     disk1s3

Note, a new EFI partition was also created. Clearly, both the Disk Utility and diskutil are doing more thinking that simply formatting a partition.

In all of the above cases, the newfs_exfat -v MyExFAT /dev/rdisk1s3 command would have succeeded on an unmounted disk1s3, since this command does require the existence of any EFI partitions.

Related Solutions

MacOS – Disk Utility says: “Error: This disk doesn’t contain an EFI system partition.”

The default results of diskutil list on a clean Lion installation should be as follows:

mac:~ me$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            499.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

My definition of a "clean install of Lion" involves letting Disk Utility from the installer partition the drive as GUID and telling it to use all space as a single partition.

Furthermore, your disk0s1 / EFI partition shouldn't show as partitioned according to disk utility:

mac:~ me$ diskutil info disk0s1
   Device Identifier:        disk0s1
   Device Node:              /dev/disk0s1
   Part of Whole:            disk0
   Device / Media Name:      EFI system partition

   Volume Name:              Not applicable (no file system)

   Mounted:                  Not applicable (no file system)

   File System:              None

   Partition Type:           EFI
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 SATA
   SMART Status:             Verified

   Total Size:               209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Blocks)
   Volume Free Space:        Not applicable (no file system)
   Device Block Size:        512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)
   Ejectable:                No

   Whole:                    No
   Internal:                 Yes
   Solid State:              No

Since your mac will boot, it may be overkill to erase everything and start over, but your EFI partition is hitting a check that Apple built into the Disk Utility, so do know that future updates could have problems and you might be forced to re-do things at a time less convenient if the difference between your system and an expected / Apple generated EFI actually breaks something Apple changes down the road (or when certain expected conditions arise like a firmware password, etc...).

On the flip side - it could be a simple check to alert you of a non-standard EFI and not that your EFI is in some way ever going to break. Can another vendor support your Microsoft EFI? If so, you might be able to leave it as is since it appears you are clearly using tools designed to make proper changes even if Disk Utility isn't able to guarantee the changes are appropriate.

How to partition the Macbook Pro’s hard disk

Lion has a hidden partition which contains recovery information. Shrinking the partition, according to an Apple employee, is not supported. He hooked up my MBP to an external hard drive and wiped and reinstalled Lion in order to fix things.

In more detail, what happens is this: When you try and resize the main partition, it doesn't include the recovery partition. When you hit "Apply Changes," it does a checksum to make sure that nothing's accessing the drive. It then gets started, doing another checksum, and discovers that something's changed, breaking the previous checksum.