If I install Windows then Linux Mint in dual partitions, the bootloader in Mint will detect both OS and I can dual boot.

If I install another Linux distro alongside these 2 but do not install/update GRUB at that time, will GRUB detect the 3rd OS?
Is it a case of re-installing GRUB or updating it?
I suppose it sits independently in a partition or sector of its own on the HDD?

I had Windows and Mint on my PC, then installed GhostBSD alongside both OS. There was aan option to install GRUB during the installation and I went for it. However, when I restarted, BSD was the only OS available at boot, although the other 2 OSes were still there.

So I ran Boot-Repair but that left me only with Mint although Windows XP is still lurking there. BSD doesn't come up anymore.

Then I reinstalled BSD without re-installing GRUB this time and although it's installed, my bootloader screen is just the same as before - only Mint comes up. I assume that's simply because I have made no changes to GRUB.

So GRUB doesn't "detect" a new OS, it needs to be re-installed every time?

Windows had also previously disappeared from the boot options before and it magically came back after I installed another linux distro. I might try that to get Windows back but it doesn't help my understanding of GRUB that OSes can come and go unpredictably when you install it.

So if anyone could explain in simple terms how GRUB works when messing about with dual or triple boots and adding OSes alongside existing ones, that would be very helpful to me.

this is a two-step process:
first you need to create a config file for grub (which is made by executing update-grub2). That will look for bootable OSs and will construct a menu system.
next you need to boot and choose something from that menu.

In your case BSD created no menu entries for other OSs, so you need to update-grub again.

Is this approximately what Boot-Repair does?

not really, it can do much more. I do not know if it can generate grub menus properly.

The problem would appear to be the version of Grub2 used by 'GhostBSD' as generally when installing systems such as Mint will probe for other systems and create a grub.cfg boot menu with the grub-mkconfig command run at the end of the install. One simple solution to your situation would have been to install Grub2 on the partition to which you installed it rather than the MBR. You would have then been able to boot Mint and run the grub-mkconfig command. In Mint, this command is: sudo update-grub.

Take a look at the site below which explains re-installing Grub2 which you could do for Mint. Have you tried running grub-mkconfig from GhostBSD? I've never ued it so don't know what's available.

https://help.ubuntu.com/community/Gr..._Broken_System

Strictly speaking grub doesn't probe for other OS - that is performed by os-prober, an external program which grub will use if present.
os-prober has specific matching rules - if the "other" OS doesn't match, it isn't included in the boot menu.

I sort of fixed it by running Boot-Repair on a live CD but I'm now only left with Mint. The bootloader doesn't detect either BSD or Windows on my machine.
So I only get to boot into BSD only or Mint only. Can't have both or even all three.

If you are able to boot Mint, open a terminal and run: sudo update-grub and watch the output to see if the other OS's are detected and added to the boot menu. If that doesn't do it, try sudo os-prober

Since you have and are using the boot repair software, is there any particular reason you are not posting a link to the output by selecting the Create BootInfo Summary option which would give a lot more detail on your system and it's problems?

I ditched the output!
This thread is not really about troubleshooting. Mint is my main installation and it works fine. If GRUB doesn't work, I know how to fix it via Boot-Repair.

I'd rather understand what's going on, why GRUB behaves as it does, how it's supposed to behave, etc...

So next time I attempt to install another OS and GRUB, I will know what I'm doing.

I may be wrong but my understanding is that BIOS points to a bootloader on the HDD, that invokes GRUB, which (from version 2 onwards) has pointers to the installed OSs the prober found and there's a boot menu.
The initial bootloader has to be installed on the first place your BIOS looks (unless the previous ones are missing but ignore this for now) for a boot partition.
Edit: UEFI can boot from suitable partitions and doesn't care about the MBR.

With "some" distributions of Linux such as Mint, the installer will probe for other operating systems and create a menuentry for each. All Linux distributions don't do this or don't do it as well as some others and you then end up with the result you got with Ghost BSD. It's the installer as pointed out above which does this.

Your options with almost all Linux distributions are too either install to the MBR of a specific drive or to select to install to the partition on which you have the Linux system installed. If you select to install Grub to the system partition, you need a separate bootloader with code in the MBR. You then would boot that system and run grub-mkconfig or update-grub and the new install should be detected.

Your specific problem isn't with Grub, it is GhostBSD. If you want to understand Grub2, the best source of information is their online manual.

http://www.gnu.org/software/grub/manual/grub.html

As far as your problem as has already been mentioned the problem is in the probing of other distros.
This http://www.ramkitech.com/2012/01/gru...omization.html explains how grub2 works with out getting too technical. What it doesn't mention is in the distro that has grub connected to the MBR, you can add entries to the /etc/grub.d/4o_custom file that aren't picked up by the osprober so that when update-grub/grub-mkconfig is run these entries will be added to the /boot/grub/grub.cfg file. The downside is that every time there is a kernel update in the other distro you will have to re-edit the 40_custom file and rerun update-grub/grub-mkconfig to reflect the change in the distro that has grub connected to the MBR. A work around is to install grub from the distro that you keep all the time to the MBR, and the other distros grubs to their respective partitions and add chainloading entries to the /etc/grub.d/40_custom for the other distros. This is on systems that uses MBR, EFI systems work a little differently.

So my understanding is that GRUB2 is GRUB2 whether installed from Mint, other linux distros or BSD. It's the os-prober from the install that may or may not pick up all the other OSes already there?

The Grub2 Manual below indicates that running 'grub-mkconfig (update-grub in Ubuntu) will search for kernels and create the grub.cfg menu. When this doesn't work, running 'os-prober' is recommended. The page referred to is at the link below. More info on Grub2 on the Ubuntus at the second link.

https://www.gnu.org/software/grub/ma...-configuration

https://help.ubuntu.com/community/Grub2/Setup

Info on os-prober.

https://joeyh.name/code/os-prober/

I expect developers of different distros make some modifications as from my experience, some are much better than others at detecting other operating systems even if all are Linux.

GRUB is a little bit of code that loads up the rest of it from whatever thing installed it last. And loads a configuration file from that thing. Or goes into command mode if that configuration file is missing. When grub is installed it creates a configuration file (update-grub in debian). The main issue with BSD is that it tends to use ZFS and encryption which doesn't exist in linux or at least bsd's version of it in linux.

There's various ways to cope though. I tend to set my computer to boot from USB first. And I tend to install my distros to usb storage and put grub on that storage. So whatever stick is in the port is the OS that boots. No fuss, no mess, it just works. Until you have more than one OS stick connected, then you get to play OS roulette. Although my tendency towards this is that the only ports on the laptop are USB and the storage that came with the device is soldered to the motherboard and will someday fail.