1

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:

  1. Windows EFI
  2. Windows OS
  3. Linux Root
  4. Linux Home
  5. macOS EFI
  6. macOS
  7. 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

2
  • Have you considered a virtual machine route?
    – Solar Mike
    Nov 28 '21 at 10:04
  • Nope. I've got it working now. I rebuilt the Windows EFI partition so have all three OSs multibooting on the same disk. My question remains: I used macOS Disk Utility to make a change to a partition and this seemed to delete the Windows (first) EFI partition on the disk. Why is that? Nov 28 '21 at 12:56
1

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.

4
  • Thanks David. My rationale for two EFI partitions is some comments I read about Windows Updates could mess with other OS bootloaders in its EFI partition. Maybe I'll try with one EFI. My Windows EFI is only 100MiB which from other reading around might not be big enough as I was getting a Media Kit reports not enough space... when trying to use Disk Utility to just erase that exFAT partition and format it again as exFAT. I didn't have that problem on another drive with macOS installed first and which has a 200MiB EFI. Maybe that newfs_exfat command won't need to use the EFI at all. Nov 28 '21 at 16:11
  • But I am curious to know what is happening? Why that first EFI gets changed to unpartitioned space? From testing it happens when using Disk Utility that changes in some way the partition layout and structure on the drive. Nov 28 '21 at 16:14
  • 1
    The Disk Utility does not have a format button. Instead there is an Erase button. The Erase operation involves at least deleting the partition, creating the partition and formatting the partition. The deleting and creating involves writing a new partition header and table to the beginning and ending of the drive. Somewhere there is code that eliminated the first smaller EFI partition and then used the larger remaining EFI partition to complete the operations. Apple does not publish the source code for Disk Utility or diskutil, so you have to learn the behavior through experience. Nov 28 '21 at 20:09
  • Brilliant answer David. When I use the asr restore... command from Terminal to restore a macOS backup image I see it has validating and verifying steps. Maybe Disk Utility does that too in the background when restoring. Maybe part of those checks end up removing EFI partitions on the drive that don't meet macOS specs e.g: at least 200MiB. A work around could be to simply use GParted to temporarily change the partition flags on the Windows EFI partition to msftdata, then clone then change back. Maybe then macOS will leave it alone.. Nov 28 '21 at 23:00

You must log in to answer this question.

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