I want to dual-boot Arch Linux alongside Windows 10, which is already installed.

I am using UEFI-GPT.

On Windows 10 installation, it creates an EFI system partition as required by UEFI. This partition's capacity is 100 megabytes. On the Arch Linux installation guide listed on the Arch Wiki, it displays that I need to create an EFI system partition that is 260-512 megabytes of capacity . Which according to that statement is not enough for my 100 megabyte EFI system partition that Windows 10 has created on installation. On the ArchWiki EFI system partition: Check for an existing partition page, it displays if I already have an EFI system partition I can simply continue mounting the partition.

Will I have any problems with only 100 MB EFI partition, or do I need to extend it somehow by moving partitions around or create another one?

The boot loader I will be using is GRUB2.

1 Answer 1


If Arch's filesystem layout only places grubx64.efi (and possibly the GRUB2 configuration file) to the EFI partition, 100 MB is fine.

But if your layout mounts the EFI partition as /boot (rather than /boot/efi) or otherwise causes the entire kernel + initramfs files to be placed in there, you might run out of space with more than just one or two kernel versions installed. That is going to make kernel updates unnecessarily risky.

You'll always want to have at least two kernels installed: the one you're currently using, and the previous one as a known good back-up. When you are installing a new kernel, that means you'll end up temporarily with three kernels installed: the old, the current and the new one.

If you are brave, you can always delete the old kernel (+ its initramfs file) just before installing a new kernel, but in a production system I would not like to do that.

(Disclaimer: on my main home system, I used to have precisely such a layout before I replaced the system disk with a bigger one.)

Note that the EFI system partition is often formatted as FAT32, and that filesystem type has a minimum number of blocks requirement. If your disk uses classic 512-byte blocks, 100 MB works out fine. But if you later migrate your system to a new disk that happens to use the new 4096-byte blocks, the minimum size of a FAT32 filesystem works out to a little less than 260 MB. As a result, 260 MB is a good forward-compatible minimum size for the EFI system partition for new installations. 100 MB can be a bit too small if you dual-boot.

(Windows 10 uses that size too if it detects the disk is using 4096-byte blocks.)

And yes, with a tool like gparted you could resize or move the following partitions further on the disk, and then resize the EFI system partition. Such an operation would be best done by booting the system from an external media, such as some Linux Live DVD/USB, so that the filesystems you'll need to move won't be mounted and in use at the time.

  • Thank you, this is just what I needed. My layout has the EFI partition mounted on /mnt/EFI. Is it the same as mounting it on /boot/EFI?
    – Zethex
    Commented Jan 29, 2019 at 9:07
  • The important thing is that it's not mounted to /boot, where the new kernel and initramfs files get installed by default. So yes, in those terms it's the same. And it looks like the Arch wiki actually suggests using /efi as the mount point for the EFI system partition if you're using GRUB. If only grubx64.efi is placed in the EFI system partition, any updates to it will be very infrequent and so it matters little where it's mounted.
    – telcoM
    Commented Jan 29, 2019 at 9:21
  • But if you also place the GRUB configuration file onto the EFI system partition, then that file will need to be updated on every kernel update, and you'll want to use any available automation to make it happen as smoothly as possible. At that point, a standard mount point would be important to minimize the need to edit any update scripts provided by the Linux distribution.
    – telcoM
    Commented Jan 29, 2019 at 9:23

You must log in to answer this question.

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