Dual booting two versions of Kubuntu on ASUS firmware

[Qqmike]

meant to use this link, easier to read as a separate post:
https://www.kubuntuforums.net/showth...l=1#post372371

[Qqmike]

I did a fourth experiment dual booting two Kubuntu versions, GRUB 2 - ESPs - rEFInd, this time using two drives (a HDD and a flash drive).
Kubuntu 14.04 & 15.04
https://www.kubuntuforums.net/showth...746#post371746

[SteveRiley]

I wonder if this is direct booting by the stub loader method?

Yes. Linux kernels have contained EFI boot loaders for some time now. The Windows kernel does not; it still relies on a separate EFI boot loader.

[Qqmike]

Yeah! That would work perfectly. For the average user, it would be really great if the field containing the version # were editable. But if you know how to cook these up yourself, well, you can just make them ad hoc. Nice. When you get UEFI and install rEFInd, you'll be ready to go. (As my posting above indicates, I decided, anyway, to go text mode, no icons; partly because seeing 5 identical Ubuntu logos was overwhelming when I have NO Ubuntu's on the machine. There is a Kubuntu logo in the icon file, but it is generic--no version # option.)

[oshunluvr]

You mean something like:

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

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

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

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

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]

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]

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]

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]

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 ...

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