Me too.
However, since the “letter” of the text, in my opinion, is not clear and exact, it felt a bit like making assumptions about someone else’s assumptions. But as a discussion is interesting.
I like bootloaders, so let it load and boot 
What would be an example of a disadvantage of mounting the ESP at /boot?
1 Like
Clowns are strong on Clowning! 
When using grub specifically? They are several off the top of my head:
- Your kernels and initrams now sit in the ESP so ESP size could become an issue
- If you use filesystem snapshots, your kernels and initrams are now outside the filesystem making recovery more difficult and making booting off snapshots not really a viable option
- If you use encryption, the files in /boot are no longer encrypted
- If you multiboot your kernels may conflict with each other since they share the same space
Conversely, there are also advantages to that approach:
- If you use encryption:
- Your decryption will be much faster
- You can apply plymouth to the decryption prompt making it look much nicer
Personally, I never mount my ESP at /boot. I mount it at /boot/efi for grub and /efi for everything else. However, there are some situations in which it can be better to mount it at /boot such as when you use refind and encryption.
2 Likes
How is that? I mount at /boot, on a 1G partition. I can boot into snapshots, but haven’t testing restoring from within a live snapshot.
When booting into snapshots, I have to choose kernel though. I wasn’t aware that it isn’t included in the snapshot?
Or rather, I perhaps was or should, but it’s been a bit much over the last week. Should be a given.
Figured I’d finally arrived at the immaculate installation scheme and could rest on my laurels. But it’s back to the drawing board AGAIN, it seems. OK, at least I’ll learn something.
Try booting into an older one, where the kernel has changed has between snapshots. The kernel in the ESP will be newer than the kernel modules in the filesystem.
1 Like
OK, I seem to get the gist of it. Gonna read up a bit and return to the drawing board one last time.
Thanks!
When you mount the ESP at /efi, where do the kernels and images go? In /boot still? In which case, what is the difference between mounting at /efi and /boot/efi?
1 Like
Yes.
Not a lot. The biggest differences are that /boot/efi is the default for grub and people who use grub generally expect the ESP to be mounted at /boot/efi
3 Likes
Of course, in the last few years I have not seen any rEFInd issues. Come to that, there’s only been updates about once a year 
i wonder if this affects legacy bios ? everything looks fine here
If I remember correctly, Legacy/MBR systems were not affected by this issue already when the whole thing started a few months ago.
There is not an active issue. This is reminder of the recommended steps to take whenever there is a grub update.
Even though the prior issue only impacted UEFI systems, you should still follow these steps with a legacy system. If you don’t, the boot image will never get updated.
That being said, relatively speaking, it is more important to do it on UEFI systems where it is more likely for there to be changes between versions. I am not sure how often the legacy boot image actually changes.
1 Like
solved from my side :
5 disks , one manjaro with r < 322 ( it’s ok )
4 disks with each /boot/efi for endeavouros
on first update , all entry from endevoursos was removed after grub-intall and mkconfig commands
==> apply 4 arch-chroot from USB iso endevouros
so one disk r < 322
one with r415 , 3 others with r403 ( from iso )
update and reboot without command grub is ok
Is reinstalling Grub recommended only on EFI systems or also on MBR systems?
it should be done in any case simply to have the latest state.
It is not said that not doing it will cause issues in any case… but as we know it can happen.
And it could happen next time you change something that needs grub.cfg regenerated and you have no clue why it happens, maybe half a year after the last grub update…
The recommendation is added after the last big grub issue where users were not able to boot the system.
Where the issue was that only grub.cfg was updated but not the grub system files (grub-install) which were causing inconsistency in the bootloader.
But yes indeed you are free to do this or not it is your system and you follow your rules.
2 Likes
I thought running sudo pacman -Syyu would automatically update your grub?
It will update the package named grub but it won’t go update the bootloader.