I am not sure about that…
I have an older bios with 2 modes called Legacy and UEFI Compatability.
I install everything in the latter mode and grub goes in the EFI partition, but I can and do put a second copy of grub in a bios-grub partition and I can boot with it in Legacy mode.
I think my UEFI Compat mode may not be the same as a modern full UEFI mode?
My understanding used to be that if a distro updated a kernel, you needed to go to the distro which controlled grub, and do update grub.
You would only need to do update-grub in the distro with the updated kernel if a recent upgrade had changed /etc/default/grub.
Now I am not sure. You may always need to do update-grub in a distro which updated a kernel. And you would need to do it first, before doing update-grub in the grub controlling distro.
I’m not sure either. I’ve just used to do it anyways after major updates.
Thanks, Neville, for letting me know. 
I was asking this question as - in the future - I might install a 2nd Linux distro on my PC´s internal disk. That´s where WIN 8.1 is still residing at the moment.
I´d like Linux Lite (which is installed on the external HDD) to be in charge of grub.
Thanks again and many greetings from Rosika 
P.S.:
Thanks. This info may come to be very useful for me.
OK!!! Why?
It is part of my learning how to use runit properly.
My impression with runit in Gentoo is that it is a whole lot of work , and you do not end up with anything better than OpenRC from a users point of view.
The biggest problem is that the Gentoo packages do not provide
runit scripts, they provide sysVinit scripts, so it is easier to stick with sysVinit with OpenRC on top of it. That works fine.
After reading all the posts in this thread, I’m glad my Solus Linux uses systemd-boot 
- it seems more straight-forward from where I sit, not to mention that Solus supports Secure Boot out-of-the-box, so no matter whether I have that feature enabled in the UEFI or not, everything works very stably and as expected. At some point, I want to learn how to use systemd-boot on distributions that use other boot managers by default (such as grub, et-al). IMNSHO, Grub/Grub2 may be the most widely used boot manager(s) but they’re way too complicated/convoluted for me. While I agree that systemd encompasses too many functionalities in a single behemoth object, each component can easily be mastered and used with a little effort. Even though it doesn’t comply with the most fundamental GNU/Linux philosophy of “Create small things, each of which does one small job very well, then combine those things to do much bigger, more complex jobs.”, I like how easy it is to learn how to use its components. Maybe the boot/system management functionalities found in GNU/Linux distributions may be best managed by such a behemoth as systemd after all.
My2Cents,
Ernie
I hope not. I would like to think there is a better solution than
a behemoth. I agree grub is far from perfect, and can be a real challenge. A new separate singleminded boot utility would be a good project.
I agree, but there is an existing project - rEFInd, and I like it a lot. It works as well on BIOS-based hardware as it does on UEFI-based devices, with or without Secure Boot enabled. It is as capable as Grub/Grub2 in either text or graphics mode without all the configuration complexity, and it can be configured to support your mouse when used in graphics mode, providing your device has mouse support early enough in the boot process. On UEFI-based devices, it installs to the refind directory on the EFI partition and has one text-based configuration file (stored in the same directory). As I understand it, at boot time, refind searches the EFI partition for bootloaders/bootable kernel images, then displays an icon/text option for each one in the boot menu. The user selects the option to be booted, and refind takes care of the rest.
I haven’t used it in a multi-boot configuration yet (that could make for an interesting experiment) so I can’t say how things would work if two or more distributions have boot images with the same name (vmlinuz for example).
Ernie
Yes, rEFInd is definitely in the mix.
Does it do legacy boot?
We need to look at how it copes with multiboot… there is a project for you… you have a headstart on everyone with rEFInd.
Thanks for the summary of how rEFInd works.
It is an independent project, isnt it?.. not GNU.
Here’s the rEFInd documentation site: The rEFInd Boot Manager
I know that it’s a project from Roderick W. Smith, but he doesn’t mention anything about licensing as far as I can tell. If you scroll down the page, there are links to other bootloaders and EFI referencing information. I know that rEFInd is intended to work with EFI/UEFI-based systems, but IIRC, I was able to use it on my old BIOS-based Acer laptop PC as a short-term experiment.
Correction: rEFInd is for EFI/UEFI-based computers. It is not intended to run on BIOS-only computers (pre-2011 machines), although it is intended to (and does) work well on computers running in CSM (BIOS compatible) mode as well as in the default EFI mode with Secure Boot disabled.
Update: After looking over the rEFInd Features page (The rEFInd Boot Manager: rEFInd Features), under the Platform Support section, there is a statement “rEFInd is licensed under the terms of the GNU General Public License (GPL), version 3.”, so even if it is not identified as OSS, it is GPL 3 licensed.
I hope this page helps to answer some of your questions,
Ernie
Yes, it helps, thank you.
It says it deals with multiple OS’s
Yes. I have Manjaro Linux dual booting with Windows 10 on my old Dell laptop PC with Secure Boot enabled. I’m using rEFInd on that computer, and I plan to add Debian 12 to the mix without installing a bootloader. If things go as I expect, Debian will boot successfully after installation and rEFInd will simply have an icon for it on the boot menu without me having to do anything special. If that’s not how things go, I’ll tell you what I learn. Maybe I’ll add another post on the subject so others can learn from my experience too.
Ernie
My guess is that the /etc folder isn’t accessible until the system has already booted some way into the selected system. Therefore, in order for a boot parameter to take effect, it has to be in a place that can be accessed at the point the selection is made.
This would be consistent with having to update grub, even in a single boot system, before the change is effective.
Of course, that explains everything.
That is why grub.cfg is in /boot
Thank you John
This statement I made earlier was incorrect. rEFInd is intended for use with UEFI/EFI/GPT based computers, whether Secure Boot is enabled or not. My appologies,
Ernie