Grub2 problem - can only boot to 2 of 3 OS's

[Colin Watson]

On Thu, May 28, 2020 at 09:46:12PM -0500, jim wrote:
> I had a system with Mint18.3 and Ubuntu18 installed.

(Note that "Ubuntu 18" is not a thing.  I guess you mean Ubuntu 18.04
rather than Ubuntu 18.10.)

> I had 100GB of free space at the end of the disk. I decided I wanted
> to install mint19.3 in the free space. I booted from the Mint19.3
> install dvd. I used gparted to shrink the Ubuntu partition so I ended
> up with about 195GB of free space. I then had gparted create a new
> partition in the free space and installed Mint19.3.
> 
> This is my configuration:
> 
> Partition 1 = sda1 - Ubuntu18
> 
> Partition 2 (extended) = sda6 - Mint18.3
>                          sda5 - swap
> 
> Partition 3 = sda3 - Mint19.3
> 
> When the Mint19 install rebooted the first time I noticed the grub menu was
> visually much larger looking than I normally saw under Mint18.3 but I didn't
> think much of it. When I was done working with Mint19.3 I restarted the
> system when the overly large grub menu cam up the only options were Mint19.3
> & Ubutu18, Mint18.3 was not shown.
> 
> I booted to Ubuntu and did some googling and read the solution was to run
> sudo update-grub2. I ran it. As the output scrolled by I did see Mint18.3,
> but when I rebooted Mint18.3 still was not an option. I booted to Mint19.3
> and ran the sudo update-grub2 command but still Mint18.3 is not an option in
> the grub menu.

At a guess, this suggests that the GRUB installation that's actually
booting your system isn't the one that was installed by Ubuntu, so
changing /boot/grub/grub.cfg in Ubuntu by running update-grub isn't
achieving anything.  Mint 19.3 probably installed its own GRUB instead.
It's not clear to me why running update-grub in your Mint 19.3
installation didn't fix it though; the above doesn't have quite enough
details to figure that out.

The first order of business here should be to reduce confusion.  I'd
suggest either dropping to the GRUB command line and working out which
GRUB installation you're actually using by looking at the $root
variable, or else making temporary changes to /boot/grub/grub.cfg in
each of your three OS installations of some kind that will be visible in
the menu so that you can work out which one currently owns the boot
process.  You should then modify all but one of your OS installations so
that *exactly one* of them thinks that it owns the boot process,
probably by removing the appropriate boot loader packages from them so
that they don't e.g. try to run grub-install on upgrades.

(Note that grub-install's job is to install the actual boot loader code
somewhere where the computer will run it when it starts up, while
update-grub's job is to regenerate the boot loader's configuration
file.)

This sort of thing is a hazard of multi-booting: you have to have a very
clear mental model of exactly how you want your boot sequence to work.
For this reason I recommend against the practice except to experts.
Approaches such as virtual machines have different downsides, but they
at least avoid this category of problem.

-- 
Colin Watson (he/him)                              [cjwatson at ubuntu.com]