Dual booting two versions of Kubuntu on ASUS firmware

[Qqmike]

With rEFInd (or Gummiboot), you absolutely can do this.

I believe you, of course ...
but,
I sure don't see how. Unless ... rEFInd goes beyond what it sees in the single directory /boot/efi/EFI/ubuntu (because it will only see one set of grub files there), to actually find the various (K)Ubuntu's and Mints that exist on your PC, and then, somehow, to use the native GRUB of each, the one you'd find in each OS partition's /usr/lib/grub/i386-pc or wherever, to somehow boot that specific OS; or to find each kernel and do the stub boot thing.

Of course, what I'd like to see is a system where when you install multiple versions of (K)Ubuntu's on the PC's single HDD, there would be created (like that passive tense?) separate directories for each one, /EFI/ubuntu-n (or whatever, /EFI/Kubuntu1404, /EFI/Kubuntu1504, etc.), AND, therefore, you could enter your PC firmware and see the full boot menu of all OSs (a separate NVRAM variable bootXXXX, for each (K)Ubuntu). IMO, THAT is exactly as it should work, if, as you say,

one of the design goals of UEFI is to easily handle multibooting...

And,

It's because GRUB tries to take control of everything. You can't have two kings, after all, heh.

Exactly. Why do "we all" allow the GRUB crew to ruin this UEFI show?! Why couldn't "they" develop a better UEFI version of GRUB 2 that does play nicely (in the context of my example, "Dual Booting Two Versions of Kubuntu..."). A better GRUB could ask you, the person installing OSs to his/her PC, in and Advanced menu, what to do with each OS installed, for example.

[SteveRiley]

I sure seem to be resisting rEFInd; your posts have prodded me, another acquaintance on another board has been also. I'm hesitant only because I'm stubbornly experimenting to see if I can find solutions to various setups that only require the basics--the Kubuntu installer plus the GRUB 2 (which, I agree, is way too complex, I am not really comfortable with its details, I only use a few commands or ... or ... Boot Repair).

GRUB had to evolve into a mini operating system on its own so that it could handle complex multiboot scenarios in the days of BIOS/MBR. There is simply no reason to use it with UEFI/GPT, as one of the design goals of UEFI is to easily handle multibooting.

rEFInd depends on one person! Rod Smith. What happens if he were to stop (for whatever reasons)? Of course, he did fork a well-known project, so someone would probably step in and keep it going.

A lot of our software depends on one person. For example, KWin is all Martin Graesslin. The fact that a piece of software has a single maintainer isn't a sufficient reason to resist it, my friend

A better question is, Why doesn't the firmware offer up more in terms of user-interface boot management (without pressing a magic key to enter wonderland)? Or the Kubuntu installer? or even GRUB 2?

Likely because the UEFI spec doesn't require anything more than the simplest of tasks: list all current EFI variables that point to boot loaders. The advantage of rEFInd is its discovery mechanism: it lists current EFI variables and any other boot loaders that it can find. With rEFInd, you can boot operating systems that might have misconfigured or missing EFI variables.

Good example: You'll notice in my experiments (those linked above), I make mention about there being only one /EFI/ubuntu. There is not a /EFI/ubuntu-2, /EFI/ubuntu-3. So Kubuntu versions go there, as do Ubuntu, as does Mint, ... and, as you pointed out, GRUB keeps overwriting the existing files in that directory. This method does not keep separate the (K)Ubuntu OSs you have installed on your PC. And, unless you intervene with some GRUB commands, the last (K)Ubuntu OS you install, controls the booting of all the previous ones you installed.

It's because GRUB tries to take control of everything. You can't have two kings, after all, heh.

The problems is, so it seems, this effects how the firmware variables are set up, right? I mean, even in the firmware, you will not find separate boot options for each of those (K)Ubuntu OSs you installed.

With rEFInd (or Gummiboot), you absolutely can do this.

[Qqmike]

Thanks for your feedback. I've been reading your various posts here at kubuntuforums. You'll note in my experiment how I simply copied those /EFI/ubuntu files wherever I wished, and restored them because they were simply files--a point you have been making in your posts about UEFI. Pretty neat.

I sure seem to be resisting rEFInd; your posts have prodded me, another acquaintance on another board has been also. I'm hesitant only because I'm stubbornly experimenting to see if I can find solutions to various setups that only require the basics--the Kubuntu installer plus the GRUB 2 (which, I agree, is way too complex, I am not really comfortable with its details, I only use a few commands or ... or ... Boot Repair). rEFInd depends on one person! Rod Smith. What happens if he were to stop (for whatever reasons)? Of course, he did fork a well-known project, so someone would probably step in and keep it going.

A better question is, Why doesn't the firmware offer up more in terms of user-interface boot management (without pressing a magic key to enter wonderland)? Or the Kubuntu installer? or even GRUB 2?

Good example: You'll notice in my experiments (those linked above), I make mention about there being only one /EFI/ubuntu. There is not a /EFI/ubuntu-2, /EFI/ubuntu-3. So Kubuntu versions go there, as do Ubuntu, as does Mint, ... and, as you pointed out, GRUB keeps overwriting the existing files in that directory. This method does not keep separate the (K)Ubuntu OSs you have installed on your PC. And, unless you intervene with some GRUB commands, the last (K)Ubuntu OS you install, controls the booting of all the previous ones you installed. The problems is, so it seems, this effects how the firmware variables are set up, right? I mean, even in the firmware, you will not find separate boot options for each of those (K)Ubuntu OSs you installed.

I'm thinking about a couple scenarios I may ask about later, maybe in the context of rEFInd, but today I have it down to read, re-read on this stuff.

Thanks.

[SteveRiley]

Good work on your experiments in that other post.

I'd suggest that most of your struggles are related to making GRUB do something it really doesn't want to do -- that is, play nice with other GRUBs. GRUB is (was) a necessary beast in the days of BIOS and MBR, because these were never designed for multibooting. GRUB is basically one giant workaround for that shortcoming. UEFI/GPT, conversely, can handle multibooting with aplomb; all that's needed is a simple boot manager for selecting from the available boot loaders on all visible filesystems. GRUB is overkill for such a requirement. rEFInd is a much better tool -- primarily because it auto-detects everything that's bootable, regardless of what file system it lives on. Gummiboot is less smart; it requires all boot loaders to be on a FAT partition (typically the ESP).

[Qqmike]

Kubuntu 14.04 & 15.04
https://www.kubuntuforums.net/showth...746#post371746