In EOS there are two places where the Linux kernel is maintained. The first is in directory /boot, where there will be files like vmlinuz-linux, initramfs-linux.img and if configured initramfs-linux-fallback.img too.
The second is in the directory /lib/modules/kernelVer/. Here kernelVer is to be replaced by the output of the command uname -r. In the directory /lib/modules/kernelVer/ there will be a single file vmlinuz.
If the files /lib/modules/kernelVer/vmlinuz and /boot/vmlinuz-linux were to be compared then would turn out to binary identical. This can be verified by running the command and comparing the hash output for both the files. They would be identical.
The same behavior is observed for LTS kernels too, only difference is the filename. For initramfs this is not the case. All initramfs files are maintained only in /boot directory.
So why is the Linux Kernel kept in two different directories? Wont it be better to simply have the Linux Kernel kept in one directory? If its presence is required in some other directory then a symbolic link can do the job. So in our case the file /boot/vmlinuz-linux can be a symbolic link to the file /lib/modules/kernelVer/vmlinuz or vice versa. Wont that work?
Isnt the EFI/ESP partition, which is /boot/efi in case of GRUB2 and /efi in case of systemd-boot, only supposed to be FAT32/VFAT? /boot can be a ext4 partition or non FAT32/VFAT partition.
So if I were to make the ESP partition to ext4 then would make a symbolic link between the linux images kept inside /bootand /lib/modules work? Will the system boot?
But in that case EOS is not longer Arch, it becomes something else entirely.
Next time I feel the urge to reinstall EOS, I will make the ESP partition, i.e. /boot/efi or /efi and boot it. Let me see if the installer allows me to do so. Then I will come to know whether the system boots or not.
Aren’t those the standard EOS’ mountpoints for Grub resp. systemd-boot? So why wouldn’t the installer let you do so? And why do you think in doing so, your system won’t boot.