Dual booting two versions of Kubuntu on ASUS firmware

[Qqmike]

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

[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]

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]

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]

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.

[oshunluvr]

I still use GRUB (old machine - no EFI)). I just installed grub to the hard drive to a small partition (no OS at all) and then created a manual grub.cfg that links to the grub.cfg's on the other partitions.

I can't wait to upgrade my PC so I can dump GRUB and start using rEFInd instead.

[Qqmike]

I also always used such a dedicated GRUB partition, which basically is just a grub executable and a configfile statement. Kind of neat, clean, by GRUB's messy standards. You could also rig up something like that in UEFI. I agree about GRUB 2--it's a messy overkill, and hard to understand. GRUB Legacy was enough, imo, simple and anyone could figure it out and configure with it. Of course, its life at MBR World was kind of weirdly restrictive and narcissistic, as we all, by now, realize ...

[SteveRiley]

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.

The /boot/efi/EFI/ubuntu stuff is all GRUB's doing. If you use rEFInd and then purge all GRUB packages, you can delete that entire subdirectory. Here's what you'll be left with:

steve@x250:~$ [B]tree /boot/efi[/B]
/boot/efi
└── EFI
    ├── refind
    │   ├── drivers_x64
    │   │   └── [I]{...filesystem drivers appropriate for your installation...}[/I]
    │   ├── icons
    │   │   └── [I]{...list of icon files znipped to zave zpace...}[/I]
    │   ├── keys
    │   │   └── [I]{...list of certificates also znipped to zave zpace...}[/I]
    │   ├── refind.conf
    │   └── refind_x64.efi
    └── tools
        └── shell.efi  [I]{...not included; you'll need to download...}[/I]

And you'll see that only rEFInd has an NVRAM variable:

steve@x250:~$ [B]sudo efibootmgr -v[/B]
BootCurrent: 0013
Timeout: 0 seconds
BootOrder: 0013,0007,0008,0009,000A,000B,000C,000D,0012
. . .
Boot0013* rEFInd Boot Manager   HD(1,800,100000,acf1ebe5-edcc-45ab-aea0-203666021f70)File(\EFI\refind\refind_x64.efi)

During boot, rEFInd searches all discoverable file systems for EFI boot loaders. For Linux, that's all modern kernels themselves. For Windows, that's the file bootmgfw.efi. You can have as many Linuxen and Windowses as you wish. You would instruct them never to create boot files during installation. rEFInd finds them all and presents them in a nice list.

In its default, rEFInd presents a graphical display with various operating system logos. I don't like that, so I configure mine for text mode. Here's my rEFInd configuration file:

steve@x250:~$ [B]cat /boot/efi/EFI/refind/refind.conf[/B]
timeout 20
textonly 1  [I][COLOR="#008000"]<-- text mode list[/COLOR][/I]
use_graphics_for  [I][COLOR="#008000"]<-- also launch all operating systems into text mode; let the OS dictate when to switch to graphical[/COLOR][/I]
scan_delay 1  [I][COLOR="#008000"]<-- without this one-second delay, rEFInd loads before file systems are detected[/COLOR][/I]
also_scan_dirs + @/boot  [I][COLOR="#008000"]<-- needed to find boot loaders (kernels) on Btrfs filesystems[/COLOR][/I]

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

When you use rEFInd, you won't have multiple NVRAM variables and multiple loaders stored under /EFI. Only rEFInd is here; rEFInd displays the list of discovered bootloaders each time you boot the computer. That's why it's superior to Gummiboot and to the UEFI bulit-in boot manager. Both these tools require you to manually copy all bootloaders (kernels for Linux, that .efi file for Windows) from their normal locations to the ESP itself. That's extra work that you must remember to perform each time you upgrade a kernel.

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.

I suppose GRUB simplifies tasks for distribution maintainers; they need to package only one boot manager into their distros and it'll work (mostly) anywhere. But on UEFI machines, it's just a big pile of complicated and unnecessary cruft. C'mon dude, make the switch!

[Qqmike]

Hey, thanks for that explanation on rEFInd, nice job. (I also don't like rEFInd's graphical boot menu ... good for the text option.)

C'mon dude, make the switch!

I may. I should anyway, to learn/test it. And I could keep my existing /EFI/ubuntu directory and contents, right? In case I un-install rEFInd? (Or, I could copy-backup the contents of /EFI/ubuntu, delete it, and later mkdir /EFI/ubuntu if I un-installed rEFInd. But, if I kept /EFI/ubuntu, I would suppose that rEFInd would ignore my /EFI/ubuntu directory anyway and call efibootmgr to set itself up as #1 in the boot order, you think? Now that would be cool.)

[SteveRiley]

rEFInd will set up its own /boot/efi/EFI/refind subdirectory and place everything there. It will create its own NVRAM variable and set that to the highest boot priority. When you then boot the computer, rEFInd's list will show all discovered kernels, Windows (if you have it), and GRUB (rEFInd detects GRUB's EFI loader).

So, it peacefully co-exists with what's already installed. Once you get familiar with rEFInd, you can purge all the GRUB related packages, remove GRUB's subdirectory in the ESP, and delete its NVRAM variable.

[Qqmike]

Thanks for confirming.

I think I just want some option (short of booting a live rescue medium and re-building from there) of booting should something weird go wrong with rEFInd, like a bad/quirky rEFInd upgrade or something.

[SteveRiley]

Best way to install it is via Rod's rEFInd PPA. Installing the package automatically kicks off the script to install and configure rEFInd itself.

[Qqmike]

Ah! Exactly my style (or a double-click .deb ...)
Thanks.

[Qqmike]

Got rEFInd installed. It's all there on Rod's launchpad page.

No problems.
Re-boot to see that it works -- OK.
Re-boot again, F2 to enter ASUS UEFI setup and boot manager, to see that rEFInd is there.
I kept my existing GRUB 2 setup, /boot/efi/EFI/ubuntu.
Tested my ASUS boot manager Boot Override to see that I could bypass rEFInd using my old GRUB 2 setup--works fine.

sudo efibootmgr -v checks out.
For now, this is the way I prefer to have it, with rEFInd as #1 and my old GRUB 2 existing in good health as #2 (the shim that triggers to the GRUBX64.EFI):

 sudo efibootmgr -v
 [sudo] password for mike:  
 BootCurrent: 0000
 Timeout: 1 seconds
 BootOrder: 0002,0000,0005,0001,0004
 Boot0000* ubuntu        HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\UBUNTU\SHIMX64.EFI)
 Boot0001* Hard Drive    BIOS(2,0,00)..GO..NO........O.W.D.C. .W.D.5.0.0.3.A.Z.E.X.-.0.0.M.K.2.A.0.................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.3.C.5.F.F.X.2.6.F.K........BO
 Boot0002* rEFInd Boot Manager   HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\REFIND\REFIND_X64.EFI)
 Boot0004* CD/DVD Drive  BIOS(3,0,00)..GO..NO........O.T.S.S.T.c.o.r.p. .C.D.D.V.D.W. .S.H.-.2.2.4.D.B.................>..Gd-.;.A..MQ..L.9.R.U.4.Y.6.F.B.0.6.4.1.Y.9. . . . . . ........BO
 Boot0005* ubuntu        HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\UBUNTU\GRUBX64.EFI)..BO

And tree /boot/efi:

 tree /boot/efi
 /boot/efi
 └── EFI
     ├── my_Backups_5-5-15  <-- {my backup of my old GRUB 2stuff}
     │   ├── grub.cfg
     │   ├── grubx64.efi
     │   ├── MokManager.efi
     │   └── shimx64.efi
     ├── refind
     │   ├── drivers_x64
     │   │   └── ext4_x64.efi
     │   ├── icons
     │   │   ├── {many!}
     │   ├── keys
     │   │   ├── {whatever they should be}
     │   ├── refind.conf
     │   └── refind_x64.efi
     ├── tools
     └── ubuntu  <-- {my old GRUB 2 stuff}
         ├── grub.cfg
         ├── grubx64.efi
         ├── MokManager.efi
         └── shimx64.efi
  
 8 directories, 83 files

So, all is well with rEFInd, thanks.

I do, however, have to study his .conf and maybe switch to text mode on the welcome menu, or use Kubuntu icons, or something--need to simplify that user-space rEFInd boot menu so I can read it. I tested that icon boot menu, and it does work the way I'd expect. But I have something like 4 or 5 Ubuntu icons! I'll fix it when I start fresh tomorrow, not while having a couple beers here tonight and reading happyassassin for the past hour ...

[Qqmike]

rEFInd, icons in boot menu. A graphics guy could make his own icon, following the specs in the refind.conf file. You could simply do a colorful blue button with text "Kubuntu nn.nn," or include a Kubuntu logo in such a homemade button with the text showing the version.

I'm happy, though, with the default menu Rod has set up. With one change. I prefer the textonly mode. It is white text on black background with blue for header banner and green for the highlighted entry--very pleasing, very clear, easy to read.

Booting entries:

-- In my Kubuntu 14.04, with the GRUB 2 setup for 14.04, /EFI/ubuntu was populated with four standard grub-boot files including the executables, shim and grubx64.efi. I kept those active. I also copied them to /EFI/my_ubuntu_Backups_5-5-15. Well, they show up in my rEFInd boot menu behind the Linux Penguin icon or in the text mode as /EFI/my_ubuntu_Backups_5-5-15, and they work. Very nice! Why not keep it there? I'm in no rush to dump GRUB 2 anyway.

-- In the rEFInd boot menu, there are options to boot four Kubuntu kernels (for the two installed OSs Kubuntu 14.04 and 15.04)--the newest installed kernel and the one preceding the newest kernel. They are listed explicitly using, for example, strings like vmlinuz-3.13.0.52-generic.efi.signed. And those boot entries work to boot those kernels (and those OSs). Nice.
--> I wonder if this is direct booting by the stub loader method?

So, rEFInd is very nice, it works well, looks good, and, importantly for me, it is not intrusive or overbearing in any way; in fact, it has preserved everything I'd like to access and use, including my old GRUB 2 setup (that came with my Kubuntu 14.04 installation). And, it is fully configurable.