A 200MB size for an EFI partition is fine.. You'll see why shortly. I use this size on some kit where I need space for use with "unusual booting" e.g. booting a system from unsupported hardware (examples here include SDcards or some USB 3 hardware that is **not** initialized by the Bios).
Standard EFI partition directory tree:
Code: Select all
/EFI
├── BOOT
│ ├── BOOTX64.EFI
│ ├── fbx64.efi
│ └── mmx64.efi
└── ubuntu
├── BOOTX64.CSV
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi
You'll notice the 'ubuntu' directory. If you install Artix Linux, you would then have an equivalent '/EFI/artix' directory as well. This directory will hold similar files to those that exist within the 'ubuntu' directory.
If you install more distro's, you'll get more subdirectories that duplicate functionality and use space.. hence the recommendation to have a slightly larger sized EFI partition when multibooting (I mean 'standard' style multibooting here.)
All of this is mandated by the UEFI spec. The computer's Bios and system tools use the presence of the 'ubuntu' and 'artix' directories (and the files contained here) to detect (and list) any installed systems. Some Bios' display this in a slightly confusing manner.. partitions and devices are often listed as well as any installed OS.
The 'ubuntu' directory contains it's own 'grub.cfg' here. This is slightly non-standard. This just sets a couple of Grub variables and passes control to the Ubuntu or Mint's local 'grub.cfg'... Sound familiar?? IMHO this is slightly more robust, as some UEFI Bios are not fully UEFI spec compliant. This **can** speed up booting (by a totally insignificant amount - literally milliseconds here) as this reduces the amount of searching that Grub has to perform.
How Does This Work??
In two ways:
If the installation is correctly "registered" with the Bios etc.. (I won't go into this, as this doesn't really affect my booting method).
then the Bios can run the "default" system's 'grubx64.efi' directly. This is the actual Grub bootloader.
Some "not fully compliant" UEFI Bios don't even do this properly.. they'll use the "fall through" method.
Here, the Bios runs 'BOOTX64.EFI' (this can be 'bootx64.efi', It depends exactly where this file came from).
This file then starts the "default" 'grubx64.efi'.
If this file was installed by Ubuntu/Mint then a hard coded path within this file points to the '/EFI/ubuntu' directory.
The Artix version of this file points to the 'artix' directory.. and so on.
This is part of what causes a system to have "lead Grub".
No Grub tools will allow you to alter this hard coded path.. It is embedded at the time the particular Grub package was compiled.
Yes, you can manually alter this with a hex editor if you want to.. it's actually an embedded text string (at 0x001A0EF0 for my current 'grubx64.efi')
My booting method removes the need for any extra 'artix' directories etc. with its duplicated content. A single set of files is used for everything.
Installing Grub here allows the first stage Grub start to be totally independent from everything else.
A manually configured 'grub.cfg' here has full initial control.
If you use this method on an external drive, you retain full independent boot control.. Here, you only need to use your boot override key to start the boot process on the external drive. This means that you can use this external drive on any system.. Specifics on how you prepare the external drive for **everything** is coming soon.
Bodge99
