Question about grub when system has more than one distro.

[Kumann]

When there are more than one distro installed which one (first or last) controls grub?
If anyone of the distros changes grub will that corrupt the boot?
If one of the distros updates grub will that corrupt the boot?

[claydoh]

When there are more than one distro installed which one (first or last) controls grub?

Technically, the last one. But once you have updated grub in the other distros, any one can be used.
Remember, each distro has a separate grub, so there is actually more than one.
Each distro, and Windows, has its own separate boot loader. So each distro will have its own separate Grub.
The one that you use to boot with is simply the one you have chosen as the first boot item in your bios, or have manually selected using your system's F-key that brings up the bios boot chooser

(One exception is really old systems that do not use EFI. In this case the last OS installed is THE sole boot loader )

If anyone of the distros changes grub will that corrupt the boot?

No,
Well it can, of course, but only for that distro, The other grub boot loaders are not touched. You can choose a different boot option from the bios to boot the other distro, and its grub should be able to boot the original distro, too, at least once it has been updated to see any new or updated distros.

If one of the distros updates grub will that corrupt the boot?

No
Well it can , of course, but only for that distro, The other grub boot loaders are not touched. You can choose a different boot option from the bios

Another exception here, is installing different official Ubuntu variants or versions on the same drive, or sharing the same EFI partition. As theses are the same exact OS, installing another one this way will overwrite the existing Grub. I do believe that this is still valid today, though I well could be wrong.
ubuntu, kubuntu, xubuntu, lubuntu,, ubuntu studio.
But that is not an emergency, since that grub can boot all the distros anyway.

[jlittle]

When there are more than one distro installed which one (first or last) controls grub?

A good question (though it assumes all the distros use grub). If you don't restrain them, each distro may try to wrestle control of the boot on some updates, depending on what is in the update.

If anyone of the distros changes grub will that corrupt the boot?
If one of the distros updates grub will that corrupt the boot?

An update can break the boot, yes, depending on what you do, and what the distros do. It can get quite confusing, and a confused computer is not reliable.

The usual solution is to use the grub package that does not do automatic updates, on all but one distro, that is the designated controller. For Intel or AMD 64 bit using UEFI these days this means uninstalling grub-efi-amd64, and making sure grub-efi-amd64-bin is installed. (At one point IIRC they were set up as conflicting with each other, but I see now that grub-efi-amd64 depends on grub-efi-amd64-bin.)

On doing an install, if you can, tell the installer not to install a boot loader. If not, immediately after installing, remove grub-efi-amd64, boot into the install you want to be the controller, and rerun grub-install there. That, of course, assumes the boot loader that's just been installed can boot your designated controller distro; but if that's not the case you've got trouble anyway. Having a bootable USB handy is a good idea, and having a minimal custom.cfg that can boot the controller distro is useful, as is knowing how to use efibootmgr.

[oshunluvr]

(One exception is really old systems that do not use EFI. In this case the last OS installed is THE sole boot loader )

I take exception to this statement. It's judgmental and hurtful, sniff, sniff ... My 3 month old MSI MPG X570S CARBON MAX WIFI running an AMD Ryzen 9 5950x 16 core CPU with 64 GB RAM booting GRUB and NOT UEFI says otherwise. One could state "really old USERS that do not use EFI..." LOL

Actually, I was gritting my teeth figuring I would have to go over to the dark side of booting but to my joy discovered my new mobo has CSM Mode - "Compatibility Support Module" - which allowed me to retain a "normal" boot environment. It is interesting the different plus/minuses between EFI and BIOS booting.

I for one used to boot many OS's but now usually opt for using VMs instead. However I am wary of allowing an OS that I am using/updating/"fixing" etc. to be solely responsible for my ability to boot - for obvious reasons. So I have a dedicated OS that controls the GRUB boot and I don't update it. Each of my installs has it's grub menu but grub isn't installed to the actual boot record - just to a sacrificial partition. Operationally, each OS updates it's grub, but it's never used. Each grub.cfg is accessible from the main grub install.

So to EFI: My initial experience was very poor. I bought a laptop in 2018 with Windows 10 and EFI is required for that machine. I initially installed KDEneon along side, no problem (after a few hurdles like removing RST - groan). At some point I broke the KDEneon install so I installed Kubuntu along side so I could fix KDEneon from the machine without booting to USB. Boy did that wreak havoc. Apparently both KDEneon and Kubuntu identified themselves as "Ubuntu" to EFI. I ended up wiping both installs and just putting Kubuntu on it. KDEneon eventually fixed that so now it identifies as "Neon" but Ubuntu and Kubuntu both identify as "Ubuntu". This was probably some sort of user (me) error but too long ago to say what happened.

I haven't tried messing with EFI again and probably won't as long as I can. However, Claydoh makes a good point about EFI allowing you to boot a distro regardless of the condition of another, For many years, many of us (jlittle included IIRC) have jumped through hoops to keep our GRUB in working condition. Something it seems like EFI does a better job of these days.

[jlittle]

(One exception is really old systems that do not use EFI. In this case the last OS installed is THE sole boot loader )

I seem to remember differently.

If a distro had an update to grub, affecting the first stages of the boot, it might reinstall itself to the MBR and the MBR gap. This often would be as part of a release upgrade. Typically, the same update would apply to a lot of distros, and they'd all have a go. Typically I'd drop the least used of the distros, resulting in the grub rescue prompt at the next boot. To avoid these problems, I made a partition just for grub and made it the boot controller, had various hacks to disable grub updates on the distros. After that, my desktop went for nearly 3 years without trouble and minimal attention, just adding a menuentry for new installs, so much so that I forgot how I'd set it up.