You are not logged in.
Pages: 1
Hi.
First time installing Arch besides a Windows 11.
I noticed that the EFI volume is full.
I dont have nothing to delete there because is just W11.
this are the partitions:
https://imgur.com/a/B7JEGvN
(sorry im just from windows)
can i just resize from windows the C:? and later add that free space to the enlarge the EFI partition? is mandatory to make a copy?
Also which is a "good value" to the EFI?
Thanks
Offline
It is very unusual for Windows to fill up it's own EFI system partition, seems like you should ask on a Windows forum about that.
If you use GRUB you only need a few MiB free on the ESP so 100MiB is usually fine. I like to use 512MiB just to give room for kernel images and suchlike.
Jin, Jîyan, Azadî
Offline
well - if you install only the bootloader onto the esp the 100mb provided by windows are more than enough
running out of space sounds you mounted it to /boot and tried to also install the kernel and the initrd onto it - that also might fit but as a regular fallback initrd is bigger than 100mb my guess is that's what filled your esp
to clean it up: remove all but the microsoft stuff and start over by mounting the esp to /efi or /boot/efi instead of /boot
Offline
In my memories, there are some tools to resize partitions - like the disk application in Ubuntu Live or a Windows tool called diskgenius.
NOTE: Using the tools may cause data loss, remember to backup.
Or you can use a separate EFI partition for Arch - but sometimes it doesn't work well as it will boot Windows directly sometimes.
My advice is to give at least 350 MB for the EFI partition - for kernel, initrd, ucode, etc. or you can place the files somewhere else (like the root partition) so they will not take their place on the EFI partition.
They are the same if you don't have other needs.
Last edited by Sving1024 (2024-12-09 15:44:41)
Offline
mounting the esp to /efi or /boot/efi instead of /boot
Mounting the ESP under /boot/efi/ is no longer encouraged:
Mounting the ESP to /boot/efi/, as was traditionally done, is not recommended. Such a nested setup complicates an implementation via direct autofs mounts — as implemented by systemd for example —, as establishing the inner autofs will trigger the outer one. Mounting the two partitions via autofs is recommended because the simple VFAT file system has weak data integrity properties and should remain unmounted whenever possible.
Jin, Jîyan, Azadî
Offline
well - if you install only the bootloader onto the esp the 100mb provided by windows are more than enough
running out of space sounds you mounted it to /boot and tried to also install the kernel and the initrd onto it - that also might fit but as a regular fallback initrd is bigger than 100mb my guess is that's what filled your esp
to clean it up: remove all but the microsoft stuff and start over by mounting the esp to /efi or /boot/efi instead of /boot
Oh, yep, probably this was what happened the thing is... that today i started to try other things without looking at the forum.
Then i delete the EFI, making before a copy to make grow the partition following the documentation:
Replace the partition with a larger one
On a disk with a preexisting operation system, the EFI system partition may be smaller that recommended in #Create the partition. E.g. Windows Setup creates a measly 100 MiB EFI system partition on non-4Kn drives.
In such cases, it may be a good idea to create a new, larger EFI system partition to prevent running out of space on it.
But when i execute this:
sgdisk --align-end --largest-new=0 --typecode=0:ef00 --change-name=0:'EFI system partition' --partition-guid=0:MY-OLD-PARTUUID /dev/nvme0n1p1i get that /dev/nvme0n1p1 dont exist...
and it is right, that dont exist, i delete it.
i free (5gb from windows to the EFI file, then i end now that i delete the efi with:
Free space (100mb)
/dev/nvme0n1p2
/dev/nvme0n1p3
Fress space (5gb)
/dev/nvme0n1p4
/dev/nvme0n1p5
Free space (this was already there, something like 1.7M))
What i can do from here?
If it is not necessary maybe i can remake the efi partition with just 100MB and try again.
Can you help me?
Thanks!
Last edited by 9acca9 (2024-12-09 20:03:23)
Offline
use
cfdiskinstead
today there's not really any difference between fdisk and gdisk anymore - as modern fdisk versions are also fully gpt compliant - so it comes down to what you prefer
Offline
thanks, i try with cfdisk but i dont know how assing the uuid
thanks
Offline
forget it... i will delete all and give another try.
He we go again...........
Thank you all.
Offline
the uuids are generated by whatever tool you use to partition a drive as they are just 128 bit long random with the sole purpose to uniquely identify partitions and filesytems and drives and whatnot - and as they're random and only valid to the device there's also no security concern in sharing them in log outputs and forums posts here (and hence anybody try to "hide" them just don't understand thier meaning - they are not saved in some global database)
anyway - there'Re a few more common options:
- use the ESP for both the bootloader and the kernel+initrd - in this case the wiki recommends a size of 1gb which is quite enough to save the windows loader (which itself is rather small), some linux loader (again, the bootloaders themselfs are rather small), at least one kernel and at least one initrd for it
- use the ESP for the bootloader only - combine the windows loader and something like grub or refind have enough space on the 100mb created by a windows installer - in this case the kernel and initrd are either saved in /boot as a regular folder on the root partition or you use an additinal partition just for /boot - sometimes called XBOOTLDR - in this you mount the ESP to either /efi or /boot/efi - but NOT to /boot - as /boot will either be its own XBOOTLDR partition or a regular folder on the root partition
- use multiple ESP - the uefi spec isn't clear on this and only requires at least one ESP - there'Re now specs how a uefi should behave when it finds more than one ESP - especially laptops often have bad uefi implementations and often are designed and tested with windows only and somehow fail the moment you try to install something different - often a solution is to rely on the fallback path - but windows has a bad habit of overwriting this with itself render a linux install inaccessible
yes, dual-boot can be done - but it requires a bit of tinkering and a good uefi implementation
Offline
Pages: 1