1 HD 1 SSD, after installing Ubuntu on /sdb Linux Mint on /sda1 is not in the UEFI/Bios though sda2 and sda3 are ? is this recoverable if so how?

Question

Seems to me installing Ubuntu on sdb after 1st installing Linux Mint on sda should have had no effect on it, am disappointed as spent time configuring the Linux mint, guess I can go reinstall, but wouldn't want it to NOW mess up Ubuntu on sdb, sigh.

Actually in the Bios/UEFI it shows 2 "Ubuntu" both on the SSD, and doesn't show the HD , so it is like I'm booting off the SSD which has / had Linux mint, but it boots the HD which has "Ubuntu" ....

Restating: in the Boot Options I see only the SSD (/sda) "SATA3_1"( I see SATA3_1: SanDisk SDS; ubuntu (SATA3_1: Sandisk SDS) and another duplicate of the latter option, nothing for the HD where I installed Ubuntu(though it boots to the HD) , as if Ubuntu install on /sdb, wrote the MBR to /sda is that possible?

Edit 1:

hmm, i now see this : How To Dual Boot Ubuntu And Linux Mint update-grub in ubuntu did not fix anything so guess i'll try boot repair, sigh

Edit 2:

Well that post is circa 2011, off USB booted and ran boot repair, 1-click doesn't fix it, and the pastebin link is generic, nothing uploads, further, I do see an option to "place the boot flag on sda1 sda2 etc
however, I fear to use it, as I don't want to fix Linux Mint only to break Ubuntu....

Edit 3

fdisk -l 
Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   1050623   1048576   512M EFI System
/dev/sda2  1050624   2050047    999424   488M Linux filesystem
/dev/sda3  2050048 234440703 232390656 110.8G Linux filesystem


Disk /dev/sdb: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt


Device       Start       End   Sectors   Size Type
/dev/sdb1     2048   1050623   1048576   512M EFI System
/dev/sdb2  1050624   2050047    999424   488M Linux filesystem
/dev/sdb3  2050048 625141759 623091712 297.1G Linux filesystem 

boot-info (partial)

============================= Boot Info Summary: ===============================

=> No boot loader is installed in the MBR of /dev/sda. => No boot loader is installed in the MBR of /dev/sdb. => No known boot loader is installed in the MBR of /dev/sdc.

sda1: __________________________________________________________________________

File system:       vfat
Boot sector type:  FAT32
Boot sector info:  No errors found in the Boot Parameter Block.
Operating System: 
Boot files:        /EFI/ubuntu/fbx64.efi /EFI/ubuntu/fwupx64.efi
                   /EFI/ubuntu/grubx64.efi /EFI/ubuntu/mmx64.efi
                   /EFI/ubuntu/shimx64.efi

sda2: __________________________________________________________________________

File system:       ext2
Boot sector type:  -
Boot sector info:
Operating System: 
Boot files:        /grub/grub.cfg

sda3: __________________________________________________________________________

File system:       crypto_LUKS
Boot sector type:  Unknown
Boot sector info:

sdb1: __________________________________________________________________________

File system:       vfat
Boot sector type:  FAT32
Boot sector info:  No errors found in the Boot Parameter Block.
Operating System: 
Boot files:       

sdb2: __________________________________________________________________________

File system:       ext4
Boot sector type:  -
Boot sector info:
Operating System: 
Boot files:        /grub/grub.cfg

EDIT 4: OK, I've read your excellent, considered replies, and I'm impressed with the level of time and assistance provided. thx, so, my update is this: I gave up and reinstall Linux Mint to the SSD /sda ; Now, if I wanted to install Ubuntu onto /sdb (like changing to Xubuntu), what if I just disconnected the SSD and leave the 2nd HD on /sdb and installed Xubuntu to it, would I still have this same problem? eg after installing Xubuntu to /sdb I then reconnected the SSD to /sda ??

I don't really have the time, to sort out why this breaks, though I generally understand what your saying, I am just as likely to break the systems as fix them , as I'm not at your folks level of tweaking :) ; THAT or I just don't install a Ubuntu based system on /sdb ; like I could just install Fedora on it (in fact I had Fedora on /sdb but it has it's own issues, or maybe you could suggest something else for /sdb that doesn't require me to learn Grub and MBR speak ??

Now I guess, though, I am stuck with these multiple "ubuntu" choices in the UEFI to boot order, and if I accidentally re-chose the "ubuntu" on /sdb, I might be screwed again ....sigh

EDIT 5 oldfred, yes the 1st install of LMint had an encrypted drive. The 2nd install Ubuntu, was also encypted onto /sdb , from there I'm pretty much lost on what your saying exactly. At this point, see my 4th edit, i've reinstalled LMint onto /sda and I am unsure how to proceed any further, LMint is now fine and booting, the BIOS has two identical looking options in boot order, actually it has 3 2 says ubuntu, 1 just says SSD, .....I am assuming if I change to the other 'ubuntu' it will boot 'ubuntu' standard edition, and in all probability mess up my now, fine, functioning Linux Mint install; given my choice, I'd like to now reinstall Xubuntu onto the 2nd HD , where regular Ubuntu is now, I had been told to manual edit the partitions and do somthing called 'alongside' this time/the next time, however, I sort of doubt that I'd do that correctly, my other thought, is to remove the SSD from the SATA header, and install xubuntu onto sdb and let it auto partition, then reattach the SSD onto /sda and hopefully I could boot either the sda or the sdb and not have any issues ......but again, I am fearful of breaking Linux mint again, to which I've spend many hours again configuring to my needs ... any feedback further very welcome....... :)

Answer 1

First, a broad comment: You're trying to apply BIOS-specific boot knowledge to an EFI-based computer. This practice more-or-less guarantees that you'll end up making mistakes, because BIOS and EFI boot processes are very different. In particular, you should stop thinking about "booting a disk" and think in EFI terms -- under EFI, the firmware boots a file, which resides on an EFI System Partition (ESP). A single ESP can hold boot loaders for multiple OSes.

Now, your specific problem is a result of a couple of interacting factors:

• Unfortunately, because Mint is derived from Ubuntu but the Mint developers did not see fit to differentiate their version of GRUB (the Ubuntu/Mint boot loader), the boot loaders from the two distributions try to live in the same place. Thus, whichever one was installed most recently will take control of the boot process.
• Although each of your disks has its own ESP, the Ubuntu (and therefore the Mint) installer has a bug that makes it use the first ESP it finds, even if it's not on the distribution's main disk or if you try to force it to use something else. Please click the link to the bug. If you have a Launchpad account, you can click the link to say it affects you, which will increase the bug's "heat" and make it a little more likely it will be fixed.

As a result of all of this, you have one GRUB installed (in /dev/sda1), and it's currently controlled through Mint -- but if and when a GRUB update comes down through Ubuntu, the control is likely to switch to Ubuntu. (This is what I call a "boot coup" -- see my page on this subject -- but with the added twist that both distributions are trying to write the same files.) If you subsequently update Mint's GRUB, control would switch back to Mint.

You can at least partially separate the two OSs' boot loaders:

1. In Mint, edit /etc/fstab so that it mounts the ESP from /dev/sdb rather than the ESP from /dev/sda to /boot/efi.
2. In Mint, unmount the ESP (sudo umount /boot/efi).
3. In Mint, mount the newly-adjusted ESP (sudo mount -a), and check with df to be sure the correct partition is mounted.
4. In Mint, re-install GRUB to the ESP (sudo grub-install, probably followed by sudo update-grub).
5. If you want Ubuntu to control the boot process, reboot into Ubuntu and type sudo grub-install (and maybe sudo update-grub) to give it control. (Alternatively, you could type sudo efibootmgr -v to see the current boot loader options and then adjust the boot order with sudo efibootmgr -o #[,#,#...], but you'll need to figure out the numbers (#) for the order based on the efibootmgr -v output. Doing this will require identifying disks by partition GUID values.)
6. Be aware that boot coups are likely to happen in the future.

IMHO, though, GRUB is only a fair fit for your needs. The trouble is that GRUB's boot-time operation is far too dependent on preconfigured settings. That is, the GRUB menu is built by the update-grub script. This script is run after GRUB and kernel updates, but if you update the kernel on the OS that doesn't control GRUB, those updates will not appear in the GRUB menu until either you manually run update-grub in the OS that does control GRUB or until you update a kernel or GRUB in that OS. There's also the question of boot coups, which can be controlled (see my page on the subject), but it's easy to get confused about what's in control because the Ubuntu and Mint versions of GRUB look pretty much identical.

You might want to look into my rEFInd boot manager as an alternative. Unlike GRUB, rEFInd scans for boot loaders and kernels at every boot, so it will pick up your kernels after they've been updated no matter which distribution you use to install rEFInd. You'd still have the potential for boot coups, but at least if one happens it would be obvious. Also, you'd probably need to do some reconfiguration, including running mkrlconf in the distribution you did not use to install rEFInd and perhaps editing /boot/efi/EFI/refind/refind.conf to tweak some settings and hide the (probably now unwanted) GRUB entries.