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

[jim]

On 5/29/20 7:03 AM, Colin Watson wrote:
> 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.)

Yes the LTS 18.04

>> 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.

Right now I am stuck in Ubuntu18'04, but it at least allows me to get 
some necessary work done so I can't reboot for a little while.

I did have a look at grub.cfg,but frankly don't understand much of what 
I see there. All 3 OS's are mentioned, here is the first mention of 
Mint18.3 (the one that doesn't show in the grub menu), if that helps.

menuentry 'Linux Mint 18.3 Sylvia (18.3) (on /dev/sda6)' --class 
linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 
'osprober-gnulinux-simple-f08e269d-88f9-40b0-bd5a-db3590779afa' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos6'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 
--hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6 
f08e269d-88f9-40b0-bd5a-db3590779afa
	else
	  search --no-floppy --fs-uuid --set=root 
f08e269d-88f9-40b0-bd5a-db3590779afa
	fi
	linux /boot/vmlinuz-4.15.0-101-generic 
root=UUID=f08e269d-88f9-40b0-bd5a-db3590779afa ro quiet splash $vt_handoff
	initrd /boot/initrd.img-4.15.0-101-generic
}

> (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.
> 

For a while now when I move from one LTS version to another I have been 
installing the new version next to the current one and then slowly 
setting it up and moving files to it. That's how I moved from 
Ubuntu16.04 to Mint18.x. Ubuntu18.04 came into being because I wanted to 
test upgrading 16.04 in place. I only remember having a problem one time 
back around the time grub2 was becoming the default choice. 
Unfortunately I can't remember exactly how the problem was fixed.

When I was searching for an answer I was mention of Boot-rep[air, is 
that a good solution?

Thanks,  Jim