How to multi-boot via multiple drives on UEFI?

[Dirkoir]

Hello Gurus:

I have a UEFI laptop with an old primary hard drive with Windows 8 plus Linux Mint 17 Cinnamon double boot.

And now I have added a second new 2TB hard drive (in an optical drive caddy) on which I would like to install Linux Mint 20.1 MATE plus later 1 or two more Linux installations (to test them and to be able to install newer Linux Mint versions without instantly giving up a fully customized older one needed for my daily work).

I am very confused by UEFI, unfortunately. I wonder if it will allow me to do this.

I would like the new installation to come to the the top on the GRUB menu (or whatever menu it is) when I boot, but also still list the other OS installations as options no matter on which drives they sit. When I add more OSs I'd like them to also get included. And when the old drive dies, I would want the new drive to still be able to boot, not be killed by its boot-magic having been stored on the old drive. And, yes, I'd like to choose the sizes of the swap, root, home, and data partitions.

Any tips? I'd be so happy to get some help.

[Moonstone Man]

I am very confused by UEFI, unfortunately. I wonder if it will allow me to do this.

In one word or less, yes.

There are some caveats. Usually only one UEFI partition is allowed on a system so the UEFI partition is shared, but some distros will allow the UEFI partition to be put anywhere thus allowing a UEFI partition on a different drive. If you want the UEFI boot partition on your new drive and also want to maintain the UEFI partition on your existing drive then the solution is to remove the existing drive every time you want to install a new OS to the new drive. Some machines will allow you to manually specify the location of a default UEFI partition but most do not. You will have to rely on your machine's boot key to select the correct boot device, every time you start. It's a major pain, and you can thank Microsoft for it.

[Dirkoir]

Thanks for chipping in, Kadaitcha Man.

If I understand you correctly, are you telling me that installing an operating system (OS) on a UEFI-oppressed computer will result in the info about which partitions can be booted from to be placed in the already existing UEFI partition (often called ESP and in this case sitting on sda) even when this already existing UEFI partition sits on a different drive than the one I install the new OS on (namely sdb) despite the Linux Mint 20.1 installer DVD letting me pick the new drive (sdb) as my desired "device for boot loader installation"? --- This would then give me a boot menu (GRUB???) including both the old OSs and the new OS (like things should be, but sadly sitting on sda rather than sdb (or destroying the one on sda if setting up the new UEFI partition on sdb?))? But whenever the old drive (sda) died the new drive (sdb) could also no longer be booted from making me lose not only the first 2 OSs on sda but also any OSs installed and customized on sdb (still sitting there fully intact but no longer able to be picked to boot)?

If this were the outcome, this first method (installing on sdb with sda not removed) would get something I want (all OSs showing up in my boot menu) but unfortunately cause EVERYTHING to go to hell when the old drive (sda) dies? Correct?

Worrying about this I considered the option of installing new OSs on the new drive (sdb) with the old drive (sda) temporarily removed, and you did recommend that, warning me though that with this second method I would not get a decent boot menu then, having instead to hit some key (Esc, F2, F10, F12, or Delete) during every start-up to escape into some dynamically created manual selection menu for the OS I want to boot. Would my UEFI laptop then even offer them all as options or only those found on one of these drives, whichever one disk it prefers for some reason?

During my online searches for more info on method #2 I also came across a short discussion suggesting that following this suggested approach (of installing OS on sdb with sda temporarily removed) could kill the ability to boot the older OSs (sitting on sda) by causing a change of the disk indices (probably in the firmware): https://askubuntu.com/questions/963282/ ... hem#963417

Questions:

1. Did I misunderstand something?
2. Is there any way to repair such catastrophes? (some way to tell the computer: look, here are these OSs on these drives, put them in a boot menu and let me boot any I wish)

[GS3]

I am very confused by UEFI, unfortunately. I wonder if it will allow me to do this.

I would like the new installation to come to the the top on the GRUB menu (or whatever menu it is) when I boot, but also still list the other OS installations as options no matter on which drives they sit. When I add more OSs I'd like them to also get included. And when the old drive dies, I would want the new drive to still be able to boot, not be killed by its boot-magic having been stored on the old drive. And, yes, I'd like to choose the sizes of the swap, root, home, and data partitions.

Be careful. Less than a year ago I was trying to do pretty much the same thing and I messed up royally. viewtopic.php?f=90&t=318029

Just to make it clear: UEFI and GRUB menus are totally different. UEFI resides on the mobo, GRUB on the disk. When you boot up you get a BIOS menu with UEFI and legacy non-UEFI booting options. From there you can choose Windows or Linux. If you choose Linux then it goes to the disk and you get GRUB and choose from there what Linux you want.

When I had only LM18 I wanted to install LM19 alongside and I thought the safest way to do it was to disconnect the HDD which had LM18 while I installed LM19 in a new drive. It was a grave mistake because LM19 overwrote the LM18 entry in UEFI and later LM18 would not appear anywhere even after connecting the HDD. I had to manually rebuild the UEFI entry which was a royal PITA.

So the next time around, in another computer, I left the LM18 HDD in place while installing LM19 in a new drive. This preserved the UEFI entry but LM19 decided to copy all the old stuff from LM18, which I did not want it to do.

In summary, it is somewhat confusing and complicated and chances are something will turn up not quite like you wanted.

It has been a couple of months since I physically installed an SSD but I still have not taken the plunge to install LM20 in it, precisely because of these issues.

[Dirkoir]

Thanks for additional info, GS3! And sad that there are so many risks and complications.

Be careful. Less than a year ago I was trying to do pretty much the same thing and I messed up royally. viewtopic.php?f=90&t=318029

*gulp* At the very least I guess I'll need to make a full clone backup of sda before daring a new install attempt. (with Clonezilla, I guess, even though prior attempts have never resulted in bootable USB clones... having to buy another costly external drive for it... *sigh*... and hope to be able to repair sda from it if sda gets corrupted with new OS installs on sdb... if only UEFI were not so hostile to multi-boots)

When I had only LM18 I wanted to install LM19 alongside and I thought the safest way to do it was to disconnect the HDD which had LM18 while I installed LM19 in a new drive. It was a grave mistake because LM19 overwrote the LM18 entry in UEFI and later LM18 would not appear anywhere even after connecting the HDD. I had to manually rebuild the UEFI entry which was a royal PITA.

I guess, you're saying that the LM19 installer messed up the UEFI firmware erasing the LM18 info from it when the LM18 containing drive was disconnected?

Besides, reading your thread (the one you linked above), I couldn't quite understand the EUFI repair process with efibootmgr. (how did that command line point at the OS or its bootloader?)

So the next time around, in another computer, I left the LM18 HDD in place while installing LM19 in a new drive. This preserved the UEFI entry but LM19 decided to copy all the old stuff from LM18, which I did not want it to do.

What does "LM19 decided to copy all the old stuff from LM18" mean ?

And was an independent UEFI boot partition (ESP) created on the new drive where LM19 was installed, one that would still work when the old drive (that still has LM18) eventually may die? Or is it impossible to keep drives independent from each other in the confusing UEFI world? I also should probably mention that I read somewhere that different Linux installations tend to "fight" with each other over boot control.


Your thread also mentioned: "By the way, LM 19 by default uses a swap file rather than a swap partition, so that part is normal." Hmm... So, I won't need to create a swap partition for LM20, either, I guess. Correct? (I may still need one for experiments with other distros like a rolling release openSUSE Tumbleweed as a potential intermediary when LM upgrades fail to work for me thanks to the UEFI mess... not sure where best to place the swap partition on sdb (front or back?))


Another issue in your thread that I don't quite understand:
Q: So, If I understand correctly, when the problem first happened, and I could only see one "Ubuntu" in the BIOS menu, I could have solved it by clicking on that one Ubuntu (LM19) and going to the grub menu from there and that would show both installations?
A: Exactly. At least, that's how it works normally. Can be disabled, though, so maybe worth double-checking now, while it's fresh on your mind.
Also, that way you don't have to worry/wonder whether it will work if you need it.

Is this saying that there are TWO boot menus that show up or can be made to show up instead of only one? One supposedly BIOS or UEFI? And ANOTHER that is GRUB2? In which order?


What I am really missing is a setup that should be standard: our computers checking during the startup which drives are connected and which OSs are installed on them and then dynamically making us our boot menu giving ALL OSs an option to be manually picked, with a manual setting choice given for the firmware-stored boot order.

I admit my head is spinning.

[linux-rox]

And when the old drive dies, I would want the new drive to still be able to boot, not be killed by its boot-magic having been stored on the old drive.

Everything you want to do is common practice, albeit not all of it newbie grade, EXCEPT THIS. This would be very complicated, if it even can be done. So, leave it out. If the drive fails, replace it and reinstall the boot loaders on the new EFI partition. Burn that bridge when you get to it.

[GS3]

I guess, you're saying that the LM19 installer messed up the UEFI firmware erasing the LM18 info from it when the LM18 containing drive was disconnected?

Besides, reading your thread (the one you linked above), I couldn't quite understand the EUFI repair process with efibootmgr. (how did that command line point at the OS or its bootloader?)

The EFI list of bootable devices resides on the mobo. I have bought second hand computers and looking into the disk I could see disks and devices which were part of the system at one time but are no longer present. My system had an entry for the HDD which contained LM18 and, BTW, the entries for LM are labeled "Ubuntu" and not "Linux Mint". So I disconnected the HDD which contained LM18 and plugged in a blank HDD and installed LM19 on it. This overwrote the "Ubuntu" entry in the EFI list and when I re-connected LM18 the system could not see it at all and there was no way to boot from it.

From LM19 I edited the UEFI list and added an entry for LM18 (with help from the experts because I had no idea). Instead of "Ubuntu" I named it "Mint". So now in the BIOS menu I have two entries with different names. You can see an image of the BIOS boot menu in the other thread. First it lists EFI boot devices and, in the same screen, below, it lists legacy (non-EFI) devices.

This page explains about editing the EFI boot table. https://www.linuxbabe.com/command-line/ ... r-examples

What does "LM19 decided to copy all the old stuff from LM18" mean ?

In this install, where I left the old HDD connected while doing it, I found the new install looked around, found the old install and copied all the home directory to some place in the new install, not the new /home but just somewhere in the HDD where it was taking up space. I did not ask for that and I did not want it. I suppose I could just delete it but I left it there just in case so that system now has a backup of the /home on the old HDD on the new HDD. I suppose this might come in handy for some people but I found it confusing. I also remember a few of the choices I had to make were quite cryptic and confusing to me and this is the reason I am postponing the install of LM20 in my new SSD which has been physically installed and waiting for quite some weeks now. I am afraid the install is going to become an ordeal, like previous ones were.

And was an independent UEFI boot partition (ESP) created on the new drive where LM19 was installed, one that would still work when the old drive (that still has LM18) eventually may die? Or is it impossible to keep drives independent from each other in the confusing UEFI world? I also should probably mention that I read somewhere that different Linux installations tend to "fight" with each other over boot control.

The way I understand it the last install will include the older ones in its GRUB menu. In other words, from UEFI-BIOS it goes to GRUB and from there you can select which LM you want to boot. I am not totally clear on this because, for example, my EFI table has 3 Linux entries when I only have 2 HDD. It seems two of them point at the same HDD but I am not taking any risks of deleting one of them. Things work as they are.

If you more than one Linux installed on a system it seems Linux prefers to present you with the GRUB menu and let you choose from there rather than directly at the BIOS level.

And I must mention that I am far from an expert on all this. What I know I have learned the hard way and many of my questions here have gone unanswered. It seems this is not an area of particular interest to the community.

Your thread also mentioned: "By the way, LM 19 by default uses a swap file rather than a swap partition, so that part is normal." Hmm... So, I won't need to create a swap partition for LM20, either, I guess. Correct?

I believe all that is done automatically when you install and you do not need to be concerned with that.

Is this saying that there are TWO boot menus that show up or can be made to show up instead of only one? One supposedly BIOS or UEFI? And ANOTHER that is GRUB2? In which order?

Already covered above. On power-up computer goes to BIOS and you can select what device to boot from. If you choose a LM device you will be shown the GRUB menu which is on the HDD. So, yes, it is a two step process.

What I am really missing is a setup that should be standard: our computers checking during the startup which drives are connected and which OSs are installed on them and then dynamically making us our boot menu giving ALL OSs an option to be manually picked, with a manual setting choice given for the firmware-stored boot order.

That's the old BIOS way. It was simple and it worked so something had to be done about it. Microsoft, Intel and other experts got together, worked hard and their labor produced EFI. The only advantage I can see is that EFI can record the serial of Windows so you can re-install Windows on a new drive and it will remember and not need to be revalidated.

[Dirkoir]

If the drive fails, replace it and reinstall the boot loaders on the new EFI partition. Burn that bridge when you get to it.

Hmm... *gulp* (or *shriek*)... Since I MUST (really MUST) daily be able to do important work on my computer, I need a way to quickly repair unbootability whenever it happens. Could I get a link to instruction on how to reinstall the boot loaders?

[Dirkoir]

Sadly I've been away due to a tough job application. *sigh* (a small hint at why I must avoid messing up the boot of a properly setup LM17 even as I install and begin to customize LM20) Let's hope this thread can continue.

In short, the prior communications in this thread suggest to me that the installation of LM20 as an additional operating system is guaranteed to overwrite the LM17 boot link in the UEFI firmware.

OTOH, when I currently boot, the boot menu I get comes from GRUB2. So, shouldn't it be possible to fix the boot mess by somehow adjusting the GRUB menu?

If the installer of LM20 was obedient to my demand to install the GRUB menu on sdb, it would probably exclude the sda operating systems (Win8 & LM17). Right?

If I didn't ask the installer to install the GRUB menu (referenced via "Device for boot loader installation" apparently) on sdb, it would probably modify the GRUB menu on sda, thereby making all operating systems bootable and later, when the sda dies, making them ALL unbootable, even those on sdb. *cry*

So... if the boot menu I get does NOT come from the UEFI but a GRUB2 menu fabrication, could the best solution not be a GRUB menu editor that would let me add manually any operating systems I want to be able to boot into?

And... if GS3 and I are not the only human beings in the 21st century who want to have safe multi-booting, might not someone already have come up with a boot installation that is not UEFI registered as Ubuntu and therefore not overwritten by Ubuntu and Linux Mint installations and can therefore be set as a safe automatic default boot in the UEFI that will never get overwritten and leads into the manually editable GRUB menu so that any OS installations will always be bootable (merely perhaps needing to be manually added to the GRUB menu after they have been installed)?

[GS3]

In short, the prior communications in this thread suggest to me that the installation of LM20 as an additional operating system is guaranteed to overwrite the LM17 boot link in the UEFI firmware.

No, not at all.

[Dirkoir]

In short, the prior communications in this thread suggest to me that the installation of LM20 as an additional operating system is guaranteed to overwrite the LM17 boot link in the UEFI firmware.

No, not at all.

Hmm... having to work so hard on other stuff I may have overlooked or forgotten something in this multi-boot research. I thought you had experienced that LM installs always result in a Ubuntu boot entry in the UEFI firmware, and that this therefore always results in an over-write. Well, if it sometimes does but sometimes not, the whole thing remains confusing to me.

I made some time to read through the useful link you have given for UEFI boot entries fixing: https://www.linuxbabe.com/command-line/ ... r-examples

Fearfully, it has a segment saying that "If you have installed multiple Linux distributions on your computer, but one of the Linux distribution doesn’t have a UEFI boot entry, you can manually add it. Boot into the Linux distro that doesn’t have UFEI boot entry. Then..." --- The poster doesn't explain how to boot into a distro that the UEFI refuses to let one boot into. I suppose he assumes using the "boot key" Kadaitcha Man mentioned above. Unfortunately, I have already been blocked by my UEFI to do this, namely when I cloned the original hard disk onto an external USB-connected hard disk. In one form of cloning, the Windows OS could be made to get booted on the external drive by default, in another it could not. And LM17 could not be booted on either clone, neither by default nor from a menu. The menu coming from the "boot key" didn't offer it. Here is the post in which I reported this problem: viewtopic.php?f=90&t=313193

That's why I am still afraid to lose my laptop if I try a new OS installation (like the latest LM version).

[Moem]

Hmm... *gulp* (or *shriek*)... Since I MUST (really MUST) daily be able to do important work on my computer, I need a way to quickly repair unbootability whenever it happens.

That is why recent versions of Mint come with a Boot Repair tool included on the installation disk. Keep that disk or USB stick around, and you'll have a tool that may very well save your donkey (so to speak) one day.

[GS3]

Hmm... having to work so hard on other stuff I may have overlooked or forgotten something in this multi-boot research. I thought you had experienced that LM installs always result in a Ubuntu boot entry in the UEFI firmware, and that this therefore always results in an over-write. Well, if it sometimes does but sometimes not, the whole thing remains confusing to me.

Here;s a summary of what I wrote upthread:

When I had only LM18 I wanted to install LM19 alongside and I thought the safest way to do it was to disconnect the HDD which had LM18 while I installed LM19 in a new drive. It was a grave mistake because LM19 overwrote the LM18 entry in UEFI and later LM18 would not appear anywhere even after connecting the HDD. I had to manually rebuild the UEFI entry which was a royal PITA.

So the next time around, in another computer, I left the LM18 HDD in place while installing LM19 in a new drive. This preserved the UEFI entry but LM19 decided to copy all the old stuff from LM18, which I did not want it to do.

[Dirkoir]

So the next time around, in another computer, I left the LM18 HDD in place while installing LM19 in a new drive. This preserved the UEFI entry but LM19 decided to copy all the old stuff from LM18, which I did not want it to do.

Thanks for reminding me, GS3. What old stuff was copied?

[Dirkoir]

Hmm... *gulp* (or *shriek*)... Since I MUST (really MUST) daily be able to do important work on my computer, I need a way to quickly repair unbootability whenever it happens.

That is why recent versions of Mint come with a Boot Repair tool included on the installation disk. Keep that disk or USB stick around, and you'll have a tool that may very well save your donkey (so to speak) one day.

Wow! That is exciting news for me!

Hmmm... checking... Seems to only be available on the LM20 (and LM20.1) installation disk.


___Readings___

Instantly checking up a bit on it:

2020: https://linuxhint.com/linux_mint_boot_repair/
Quote: "From the “GRUB location” tab, you can decide the default OS to boot into. You can also place GRUB on a different device."

Could that mean an opportunity to install a boot entry in the UEFI firmware from OUTSIDE the non-bootable OS? (which the https://www.linuxbabe.com/command-line/ ... r-examples link I mentioned recently did not offer... reminder: it insisted on booting in the non-bootable OS to fix its non-boot problem from there... not explained how, possibly via a boot key approach, something I could never do on my USB-external startup-disk-clone since its OSs could not be booted via boot key)

Or does it merely fix a GRUB configuration in some boot loader luckily bootable from the UEFI where it is already installed?

2015: https://linuxmint.tumblr.com/post/92939 ... -access-to
Quote (abbreviated): "Boot-Repair ... creates Pastebin containing ... UUIDs and mount points (just disconnect internet if you want these data remain local)."

I find it a bit annoying it tries to do this by default. Shouldn't we worry about hackers? Anyway. No need to talk about this Pastebin issue. I just wanted to mention this for readers and tell them that one can deny this.

Nowwww... reading a number of posts about Boot Repair, one thing hardly addressed was multiple drives. Since UEFI requires a EFI partition (ESP) on every boot drive, this seems to suggest to me that I should create a small FAT32 partition on my second hard (sdb) drive even if the linux OS installers pick the one on the original hard drive (sda), so that later Boot Repair could switch to sdb when sda has died. Correct?


___Tests___

Summary: Boot Repair failed

Details:
I tested the Boot Repair tool (running on live LM20 ISO DVD) on my little travel laptop, the one whose OS/boot corruption wouldn't be the huge catastrophe it would be on my work laptop. In short, the problem I had of not getting into the UEFI shell ("InsydeH2O") with ANY boot key and therefore not being able to boot from the DVD I managed to solve with the terminal command update-grub when booted from the internal drive that still boots there. This also added the Win8 and LM17 list items to this travel laptop's GRUB menu when I had my old external USB disk clone of my work laptop attached when I ran the update-grub. UNFORTUNATELY, these list items did not work. Boot Repair tool modified the Grub menu (it's GRUB 2.02) by adding even more options (most of them reflecting the boot loader files stored in the UEFI partition (ESP) -- which I discovered to apparently be what looks like stuff stored on the LM root partition as /boot/efi/EFI but according to the Disks app actually is merely a /boot/efi mount of the UEFI partition (ESP). UNFORTUNATELY all the new list items in the GRUB menu ALSO don't work, always giving me the response that the 'device' (disk) does not exist even though when I boot from the internal HDD LM19 or from the live LM20 ISO DVD the external USB disk's permitted partitions instantly show up in Nemo and the entire drive in the Disks app. (repeating update-grub and wriggling with UEFI shell settings on legacy and USB fixed nothing; copying some of the .../EFI/ contained boot loader files to the .../BOOT/ folder did not help either (something I had read during my online searches had helped someone else))

Is the problem that this second disk on my test (travel) laptop is external and connected via a USB port (one I never changed during these tests, in case you wondered)? Might Boot Repair tool only work successfully on non-USB-connected disks or even only on a single primary internal one? Adding other boot loaders to the Grub menu is nice, but not helpful when picking them in the Grub menu does not get them booted.

[GS3]

Thanks for reminding me, GS3. What old stuff was copied?

I forget the details but I vaguely remember LM trying to be a little "too helpful" and copying the old home folder to somewhere in the new disk without even asking or telling. Something like that.

I have finally decided to bite the bullet and attempt to install LM20. viewtopic.php?f=90&t=343471

I believe this is made more complicated than it should be and that it could be clarified and simplified.

[Dirkoir]

Yes, multi-boots and multiple OS installations have become way too complicated and risky, and failing often in this horrible UEFI world. (ALL my attempts to boot from clones made on external USB disks have so far failed, except for the Win8 case in one situation in the past)

I wonder if the USB porting had anything to do with my problems so far. But if not, then my attempt to finally move up to LM20.1 without giving up my well configured LM17 (that took MONTHS to configure properly and will still be needed for my daily work to do until I finally get LM20.1 properly configured) will also fail, and since Boot Repair has so far failed to help, I must fear that it will fail again.

I am therefore looking into the possibility of using rEFInd as the boot manager. I don't know if it can be trusted to overcome the weird disk blockades we both have been struggling with. But if it can, then it will give us what all people deserve: a dynamic boot menu offering every available OS without ridiculous setup needs.

[ajgringo619]

I really don't think that UEFI is the bad-guy here. I've read so many posts about dual-boots, especially with Windows, that got completely hosed using BIOS/MBR; worse thing I've ever experienced with UEFI and Windows (both 7 and 10) is Windows sometimes changes the default UEFI bootloader to itself (an easy fix from the BIOS menu).

In my personal opinion, I think GRUB is the more of the problem. I recently switched to systemd-boot and have been really happy with it. There's not nearly as much documentation/examples for it, but after some trial/errors in my VM environments it's actually pretty cool.

[Dirkoir]

I really don't think that UEFI is the bad-guy here. ... In my personal opinion, I think GRUB is the more of the problem. I recently switched to systemd-boot and have been really happy with it.

I consider the possibility that the device (the external removable USB-connected HDD) on which the multi-boot exists (Win8 + LM17) is falsely defined either in the GRUB2 menu where the Boot Repair tool managed to list them or in the UEFI firmware (is that even possible when the UEFI shell (today's equivalent of BIOS interface) never ever lists them up for me?). It's all such a mess, and I do believe that UEFI carries at least part of the guilt by scattering boot management over both the firmware AND disks with disks then conflicting with each other or becoming dependent on each other. A jungle set up for problems, and GRUB set up to deal with it may also make mistakes. I cannot guarantee any accuracy of these analysis attempts since I am no expert of this and have no time to become one.

Side Note for healing imposed default boot loader issues that may come up: "If 'Windows Boot Manager' enforces/resets boot order (as described above) you can keep Windows at 1st 'boot order' but set it 'inactive' with efibootmgr. Make GRUB 2nd 'boot order' and it will boot always." (<-- source)

Question #1: Is systemd-boot an older equivalent of GRUB as I think I once read somewhere? (or a newer one?)

Question #2: Would systemd-boot match this definition of rEFInd: "rEFInd is a boot manager, not boot loader, from Rod Smith that scans for boot options at boot and displays the options to load. The options can be kernels, boot managers, boot loaders and can be from a removable drive since it scans at the time of boot." --- Note: Having OSs on removable drives automatically pop up in the boot menu AND BE BOOTABLE when picked is the Holy Grail IMHO, the way, like back in the golden computer age to remove all hurdles. Provided it reliably works, that is.

[ajgringo619]

I really don't think that UEFI is the bad-guy here. ... In my personal opinion, I think GRUB is the more of the problem. I recently switched to systemd-boot and have been really happy with it.

<snip>

Question #1: Is systemd-boot an older equivalent of GRUB as I think I once read somewhere? (or a newer one?)

It's newer. It used to be called gummi-boot; it's now part of systemd.

Question #2: Would systemd-boot match this definition of rEFInd: "rEFInd is a boot manager, not boot loader, from Rod Smith that scans for boot options at boot and displays the options to load. The options can be kernels, boot managers, boot loaders and can be from a removable drive since it scans at the time of boot." --- Note: Having OSs on removable drives automatically pop up in the boot menu AND BE BOOTABLE when picked is the Holy Grail IMHO, the way, like back in the golden computer age to remove all hurdles. Provided it reliably works, that is.

Systemd-boot is a simple boot loader, nothing more. The only thing it will automatically scan for is Windows installations. It also adds a boot entry to go directly into your UEFI BIOS settings.

System-boot doesn't actually replace GRUB - you can have both options, if you desire - but I removed it as soon as I have systemd-boot setup. One huge caveat: systemd-boot does not have the equivalent of update-grub. I wrote one myself (a fork of a bash script I found), but it's still in testing.