Am I able to install Arch Linux with the 100MB EFI partition that Windows 10 had already created on installation?

Clash Royale CLAN TAG#URR8PPP
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 1. Which according to that statement is not enough for my 100 megabyte EFI system partition that Windows 10 has created on installation. On 2 it displays if I already have an EFI system partition I can simply continue mounting the partition.
Will I have any problems with only 100MB EFI parition?
Or do I need to extend it somehow by moving partitions around or create another one (please tell me how I would do this if needed)?
The boot loader I will be using is GRUB2.
Thank you
grub2 uefi gpt
add a comment |
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 1. Which according to that statement is not enough for my 100 megabyte EFI system partition that Windows 10 has created on installation. On 2 it displays if I already have an EFI system partition I can simply continue mounting the partition.
Will I have any problems with only 100MB EFI parition?
Or do I need to extend it somehow by moving partitions around or create another one (please tell me how I would do this if needed)?
The boot loader I will be using is GRUB2.
Thank you
grub2 uefi gpt
add a comment |
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 1. Which according to that statement is not enough for my 100 megabyte EFI system partition that Windows 10 has created on installation. On 2 it displays if I already have an EFI system partition I can simply continue mounting the partition.
Will I have any problems with only 100MB EFI parition?
Or do I need to extend it somehow by moving partitions around or create another one (please tell me how I would do this if needed)?
The boot loader I will be using is GRUB2.
Thank you
grub2 uefi gpt
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 1. Which according to that statement is not enough for my 100 megabyte EFI system partition that Windows 10 has created on installation. On 2 it displays if I already have an EFI system partition I can simply continue mounting the partition.
Will I have any problems with only 100MB EFI parition?
Or do I need to extend it somehow by moving partitions around or create another one (please tell me how I would do this if needed)?
The boot loader I will be using is GRUB2.
Thank you
grub2 uefi gpt
grub2 uefi gpt
asked Jan 29 at 3:33
ZethexZethex
31
31
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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
Jan 29 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/efias the mount point for the EFI system partition if you're using GRUB. If onlygrubx64.efiis placed in the EFI system partition, any updates to it will be very infrequent and so it matters little where it's mounted.
– telcoM
Jan 29 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
Jan 29 at 9:23
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f497342%2fam-i-able-to-install-arch-linux-with-the-100mb-efi-partition-that-windows-10-had%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
Jan 29 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/efias the mount point for the EFI system partition if you're using GRUB. If onlygrubx64.efiis placed in the EFI system partition, any updates to it will be very infrequent and so it matters little where it's mounted.
– telcoM
Jan 29 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
Jan 29 at 9:23
add a comment |
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
Jan 29 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/efias the mount point for the EFI system partition if you're using GRUB. If onlygrubx64.efiis placed in the EFI system partition, any updates to it will be very infrequent and so it matters little where it's mounted.
– telcoM
Jan 29 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
Jan 29 at 9:23
add a comment |
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.
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.
answered Jan 29 at 8:48
telcoMtelcoM
17.6k12347
17.6k12347
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
Jan 29 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/efias the mount point for the EFI system partition if you're using GRUB. If onlygrubx64.efiis placed in the EFI system partition, any updates to it will be very infrequent and so it matters little where it's mounted.
– telcoM
Jan 29 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
Jan 29 at 9:23
add a comment |
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
Jan 29 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/efias the mount point for the EFI system partition if you're using GRUB. If onlygrubx64.efiis placed in the EFI system partition, any updates to it will be very infrequent and so it matters little where it's mounted.
– telcoM
Jan 29 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
Jan 29 at 9:23
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
Jan 29 at 9:07
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
Jan 29 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
Jan 29 at 9:21
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
Jan 29 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
Jan 29 at 9:23
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
Jan 29 at 9:23
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f497342%2fam-i-able-to-install-arch-linux-with-the-100mb-efi-partition-that-windows-10-had%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown