Artix Linux Forum

>Or if there is already a kernel and initramfs in /boot they are going to be older versions as the kernel gets updated..

Since in your example /boot is actually the ESP partition, I'm guessing there is a way to tell GRUB to look for the kernel and initramfs in the root of the ESP partition instead of the actual /boot.

WHY SIMPLE mounting at /boot

I went ahead and adjusted the wiki page to suggest /boot/efi as the mountpoint. It clears the BOOT/ESP confusion and doesn't break anything for people with compliant UEFI firmware if they're going to install GRUB (or any other bootloader with drivers for Linux filesystems).

[...]
A faulty UEFI implemenation. I know computers that crash if you try to install GRUB, no matter where the ESP is mounted [...]

Quick Recommendations:
Most Linux distributions install the EFI version of GRUB 2 on EFI-based computers. When I first wrote these pages, GRUB 2 barely worked, but it's much more reliable in 2018 than in 2011 [...]
There are problems with GRUB 2, though. Some of these problems relate to the fact that it can be difficult to control your boot mode (EFI vs. BIOS) when you install an OS, and therefore difficult to tell which version of GRUB you've installed. There are also cases where GRUB misbehaves; it may fail to launch, refuse to chainload to Windows or OS X, or do other strange things [...]
Be aware that there are significant system-specific quirks [...]

Once Linux is installed, the ESP is typically mounted at /boot/efi, so these directories would be /boot/efi/EFI/ubuntu and /boot/efi/EFI/redhat, respectively, on a working Linux installation. A proposal at freedesktop.org would encourage mounting the ESP at /boot rather than at /boot/efi. This proposal has yet to be adopted by any major distribution, although Arch Linux users are fond of mounting the ESP at /boot.

The $BOOT Partition Placeholder:

In the text below, the placeholder $BOOT will be used to refer to the partition determined as follows:

• On disks with an MBR partition table: → the boot partition, as described above
• On disks with a GPT partition table: → the XBOOTLDR partition if it exists
• Otherwise, on disks with a GPT partition table: → the ESP

Mount Points:
It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. If $BOOT and the ESP are the same, then either a bind mount or a symlink should be established making the partition available under both paths.

(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 —,[sic] 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.)

Creating These Partitions:

An installer for an operating system should use this logic when selecting or creating partitions:

• [...]
• Otherwise, if on GPT and an ESP is found and it is large enough (let’s say at least 1G[sic]) it should be used as $BOOT and used as primary location to place boot loader menu resources in.
  

my Arch system was bootable but overheating and crashing after seven minutes; i have checked efivars among other stuff --they were absent!!!

Are you saying that in your first example there were no efivars at all ? Or that they were null ? Or that some were missing?
But regardless I can't explain it off the top of my head.

Though judging from this post and previous threads there is something wrong with your hardware.
It seems, based on what you say, that your computer overheats and crashes at lot, and this a partly an educated guess, when under load. Personally I'd be making it my priority to sort that out and then be worrying about where the ESP is mounted 

You link Rod's site as "Roderick Smith`s site dedicated to EFI and UEFI"
This is not incorrect however I'd go with "Roderick Smith`s site: The home of rEFInd"

rEFInd is far superior to grub2. The only reason to choose to use grub is if your computer is BIOS only.
The reason most linux users use grub is because that's what the installer installs and most of them would be, with justification, scared to switch even if they knew there was a better option.

Being diplomatic grub2 is a pile of turd. Ridiculously over complicated configuration. Shitty look, Easy to end up with just a black screen, "Grub Rescue", Now what ? Whatever happened to KISS - keep it simple stupid.

rEFInd be like: "No config, who cares". "Found these installs, which would you like to boot?"

no, this my machine normally does not overheat or crashes

i have had a freezing of the system after some fifteen minutes.

the machine gets overheated before the system freezes

and i was literally exhausted after several  hours of sitting in front of constantly crashing baby

yes Grub may be quiet black-screenish sometimes, but ...as you have said 'that`s what the installer installs' and personally i am not ready to switch to another bootloader from an already installed system;

and in addition, and that`s why i have preferred Grub while planning installions --it DOES support my chosen filesystem: XFS;
among the other ones only LILO has a support for it but DOES NOT work with UEFI hardware.

[...] expressing my love for rEFInd [...] I think everybody capable should switch
Because it's better
[...] I do believe it's possible to use XFS with rEFInd as well as other, dare I say, exotic filesystems. But you need to source third party drivers. It's all on Rod's site.

It surprises me you would be adverse to switching bootloaders as you clearly enjoy tinkering. Which is a complement not criticism.

My mistake. You must have been talking about another machine in this thread.Sounds like the other machine has cooling issues ?

Quote

> among the other ones only LILO has a support for it but DOES NOT work with UEFI hardware.

There's elilo, though it stopped being developed long ago.

Quote

> It surprises me you would be adverse to switching bootloaders as you clearly enjoy tinkering. Which is a complement not criticism.

The bootloader isn't exactly something you should be "tinkering" with unless you're doing it in some kind of virtual environment, far away from the main OS. Any mistake cal lead to an unbootable system.

The bootloader isn't exactly something you should be "tinkering" with unless you're doing it in some kind of virtual environment, far away from the main OS. Any mistake cal lead to an unbootable system.