Back in the 80's, our operating system (OS) sat on a floppy disk. If you wanted to boot with a different OS you simply switched the floppy disk. Done. No problems whatsoever.
When hard drives came around, it could get more complex (in theory) because internal hard drives could not be switched so easily. (you had to open the computer, often with a screwdriver, and switch the cables). External hard drives were still quite easy to switch. And me, back then focusing on Macintosh computers (BEFORE the OSX), had it easy, too, to switch versions of the Macintosh OS. They were merely folders that could be easily copied in the Finder (the equivalent of our Nemo on Linux Mint), both to other drives and even the very same drive, very same partition. And you could easily tell your computer which of these folders you wanted to get used as the OS to boot from. With SCSI numbers you could arrange the device priorities.
In the 2000's I was forced to use Windows and used it as a single OS. Hence no possible trouble with competing operating systems. One problem I was frustrated by was the registry that didn't keep installed applications fully separate from the installed operating system (like it had been in the pre-OSX Macintoshs (not sure how it is now on OSX Macs). So, an OS update or switch left the previously installed applications unharmed, running fine as long as they were compatible with the OS version. Liberty had still existed back then. Much less on Windows. (Linux, of course, has a similar problem by merging apps with the OS -- sure, I think, this also gets used for letting applications interact with each other usefully (pipes that can be handy; still having to reinstall and reconfigure all applications after upgrading or switching an OS version is a lot of hassle, though)
Still, when I switched to Linux Mint in 2014, multi-boot was still no problem. I installed it on an external drive (YES! One connected via a USB port!) and could boot from it on two laptops which internally had Windows installed. In the BIOS (no UEFI mess, yet, on one laptop) and even the UEFI interface (modern BIOS equivalent) on the newer laptop (the one I still use as my daily super-necessary main laptop), I could simply set up to prefer booting from any attached external drive, and things went well like they had in the 80's and 90's. I was very happy. And, yes, I could even have multiple Linux OSs on that external drive, and when the laptop booted from the attached external drive automatically, I was given the startup menu from which to pick the Linux OS I wanted to boot from (there was even a tool to manually adjust the GRUB menu usefully). Liberty. Happiness. (and an instant solution after the internal drive died on the older laptop (that is gone now) -- simply boot it from the external USB drive)
But after I installed LM 17 in 2014 or 2015 on my current main laptop's internal drive alongside the pre-installed Windows 8 (a multiboot which also worked well), I soon ran into first problems. Namely cloning the internal hard drive onto an external USB hard drive specially bought for having a backup, I could not test the clone via booting from it. On the same laptop the UUID mess interferes with it (the laptop ignoring devices, only looking for UUIDs (partition IDs) which on a Clonezilla disk-clone are OF COURSE identical (and should probably stay that way for the partitions' interactions and for cloning backwards when restoring a corrupted drive or setting up a replacement drive with the already well configured Linux Mint one backed up as a clone) -- what were the developers thinking when they skipped over ports and especially devices so easily used to distinguish clones from originals?!?). More sadly, booting from this new external drive didn't even work on a new secondary laptop bought, despite the UEFI IDs being different, of course. It would only boot Windows from it (from the first clone; when I made a second clone on a second new external USB hard drive, even that would not work -- Why?!?).
Then, when I booted from the old external USB hard drive -- the one from 2014/2015 -- the one that had always worked, it worked fine the first time, but then suddenly something happened to it in that process, so it can no longer boot from it anywhere. (I suspect it had still an MBR rather than GPT partition table and perhaps no UEFI setup, but how that got it attacked and messed up by one of the more modern laptops, no idea)
I then experimented on the second laptop (the "travel laptop" which is not daily needed by me, and which originally had only one OS installed (LM 19 Cinnamon)). I shrank its LM 19 partition and installed LM 20.1 MATE alongside on its internal HD. The GRUB2 menu then had set the new experimental LM 20.1 MATE installation as the default boot (called "ubuntu", I think), something I managed to switch back to the LM 19 already configured for family members -- with a manual GRUB2 list items shift using the boot-repair tool (the Lm 20.1 MATE OS oddly named "Ubuntu", by the way, and the Lm 19 suitably named without my having to try to name it that way, as far as I recall -- unsure if I could rename these names).
I tried to get the external clones to work. Booting the "travel laptop" from the internal drive into either one of the LM OSs (19, 20.1) and then in the terminal give the command update-grub successfully added the external USB OSs (Windows & and LM 19) from a main laptop clone (plus an unnecessary bunch of ancient other drives/OSs the previous laptop owner(s) must have had (yes, I bought the laptop used), OSs that no longer exist on my end). Sadly, neither the Windows 8 nor LM 17 OS existing on the clone could actually boot when picked by me in the boot menu, the laptop giving me the response that the 'device' (disk) does not exist (despite of it being attached (even on the same port!)). (repeating update-grub and wriggling with UEFI interface settings (commonly still called BIOS when I read it no longer is BIOS) fixed nothing; copying some of the /boot/.../EFI contained boot loader files to the /boot/.../BOOT (or /boot/.../GRUB??? not sure anymore) folder did not help either (something I had read during my online searches had helped someone else) --- btw. these folder locations seem to be link-wise backdoor entrances into the contents of the ESP/efi partition from within a successfully booted Linux OS rather than some duplicate of ESP/efi partition contents)
To return to the good age of utter liberty (in other words, wishing to start any laptop and get a boot menu with ALL the operating systems from ALL its internal and external hard drives and be able to boot from any I pick), I then installed rEFInd on this "travel laptop" (via LM's Software Manager) hoping it could let me also boot from external USB hard drives to finally become able to again test or use OS clones and to possibly be able to avoid the mess of having to try to manually set up boot opportunities for additional OSs -- these setups being complex and time consuming efforts that sadly can result in getting previous OS installations unwillingly blocked from booting or later make drives unbootable when their ESP/efi partition was placed on another drive that has afterwards died or been removed. But, sadly, I now got mysteriously hit with a MOK boot blockade even though I have Secure Boot disabled. Another unsolved mystery. I had to de-prioritize rEFInd in the listing of boot OSs listed in the UEFI shell interface ("InsydeH2O Setup Utility", a modern replacement of traditional "BIOS" apparently) in order to make the "travel laptop" bootable again. *siiiiigh*
I am still unsure how to best add a new OS (LM 20.1 MATE) to my "main laptop" that I need to use daily for important work, the laptop that therefore needs to maintain its already existing OSs (Windows 8 and LM 17 Cinnamon) (Windows 8 only in case I must ever use it or even update it to Windows 10 -- let's hope neither, but LM 17 because of the many tweaks and installations that took months over years and cannot be quickly re-created in a new OS installation (LM 20.1 MATE)). I can only install a new Linux Mint on an added hard drive (already added via replacement of the optical drive) since the original internal hard drive has no room. PLUS, it may die soon. Infos I have found and tips been given so far still leave me unsure. On one hand, installing LM 20.1 MATE with the ESP/efi partition on the original internal drive being used for its boot loader would give me, when I start the laptop, a GRUB2 menu hopefully having all three OSs listed and bootable (and a future 4th one, as well). But when the old drive dies, even the LM 20.1 MATE OS on the added new drive would no longer boot, because its boot loader would have been lost. And would the "InsydeH2O Setup Utility" (today's BIOS equivalent) let me do anything? Or boot-repair run from a live CD/DVD (my LM 20.1 MATE installer, for example)? Alternatively, might it be better to get the boot loader installed on the new added hard drive (it getting its own ESP/efi partition), then never getting a GRUB2 Menu that would give me all three options, though? (plus some online posts warn against having more than one ESP/efi) --- Or could I update that GRUB2 menu somehow to successfully include the older drive's OSs as boot options (maybe by using the "boot-repair" tool when booted from LM 20.1 MATE on the added drive which most likely would be the default boot event after the installation -- or possibly by somehow copying the ESP/efi partition's contents over to the new ESP/efi partition to merge both GRUB2 menu listings -- two actions with which so far I have only had marginal successes in my experiments)? --- I also recall having read that if I wish to get the boot loader for the new OS installation (LM 20.1 MATE) -- that I install on the added new drive rather than the older drive -- likewise installed in an ESP/efi partition on that same new drive, I must first remove the esp & boot flags from the older drive's ESP/efi partition because of a current bug in the LM installer making it pick the first ESP/efi partition it finds (which would be the old drive), rather than the one selected by me (another complexity I could possibly forget to do resulting in the end of our universe). *sigh*
Yes, I am really worried that finally getting around to install the current LM version (which is highly necessary) will either kill the old one or make it unbootable, or the new installation won't be bootable, or it will become unbootable after the old drive dies. Further worries: even if the new OS installation (LM 20.1 MATE) gets to boot, AND then running the "boot-repair" tool I may even get bootability of the older OSs from the older drive merged into the added new drive's ESP/efi partition and GRUB2 menu, something else may get messed up again. One "Ubuntu" may replace another one in the BIOS-equivalent (NVRAM and/or "InsydeH2O Setup Utility") rather than having both still as options, for example (plus former owner's OS references being copied over to possibly create trouble behind the curtains even when not cluttering the GRUB2 Menu at least).
The sad thing is: I can clone (backup) my internal hard drive (and have already done so). But I cannot properly test the clone (by booting from it; since that boot has somehow become impossible even on another laptop). And I cannot back up the NVRAM (the UEFI/InsydeH2O/BIOS hardware storage of... uhm... whatever little the hardware knows... like references of where on which drive to find the boot loaders) in case the NVRAM gets messed up by the LM 20.1 MATE installer or perhaps the "update-grub" or "boot-repair" tools, or even "efibootmgr"). And the splintering of (these hardwired *sigh*) setups across the NVRAM plus an ESP/efi partition plus perhaps a second ESP/efi partition seems to create confusion not only for me but also my laptops, regularly removing available OSs from the boot menu (GRUB2 menu) and InsydeH2O boot listings or having them listed BUT not letting them get booted. So, when these things get messed up, my clone (internal older hard drive backup) will surely not help me. So, if things go wrong, there is no way to go back. *siiiigh*
And then -- *ugh* -- another warning I came across: that kernel upgrades can also mess up multi-boot even after it has been made to work.
Anyway, I am not the only one having suffered from this modern chaos. (see for example viewtopic.php?p=1801963 and viewtopic.php?p=1979681)
Someone coming up with a nice solution would be great (but seems impossible to me by now, there seeming too many chaotic hurdles and bugs in hardwares and softwares nowadays). So, this post is not a question but a story that others could add their own stories to. Maybe this would eventually even lead to recoveries or great tips from insightful experts stumbling across this. Who knows. At the very least, when I ask a small question in the future to help me fill the gaps in my UEFI & MOK chaos jungle exploration, and someone wonders what the bigger picture is on my end, I can refer to this story that summarizes my events otherwise scattered across several posts.
dirkoir
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Important vocabulary as far as I understand it so far:
Hardware thingies:
- BIOS = traditional (and dependable) startup code and prioritized list-storage firmware now apparently replaced with (chaotic) UEFI firmware, in my case calling itself "InsydeH2O Setup Utility" -- but often still referred to as BIOS by people
- NVRAM = the hardware RAM storage of what little or too much the UEFI firmware stores on the hardware to then interact or conflict with what's stored on the boot drives
- mobo = some people's abbreviation of motherboard
- MBR = partitions table on old smaller drives, now usually no longer used
- GPT = the now common partitions table (replacing MBR)
- ESP also known as efi partition (hence referred to by me as "ESP/efi partition") = "EFI System Partition", a FAT32 formatted partition on a boot drive containing boot loaders (or even a boot manager like rEFInd, as well) plus potential other utilities used by modern UEFI firmware and stored there on some drive rather than its own NVRAM (*shudder* UEFI firmware talk: "Which drive is it again that has my stuff? This one? Or that one? Or the dead one that's long gone? ..." Yep, confusion preprogrammed by design...)
- UUID = "universally unique identifier" (a joke when considering clones) an id given to a partition to address it and distinguish it from other partitions
- GUID = some other partition ID apparently; no idea how they differ from UUID and which of the two I typically see in tools.
- update-grub
- boot-repair
- efibootmgr