How do I select a different boot option using UEFI??

[oshunluvr]

OK, efi smarty-pants people, help me out.

How do I select an alternate kernel using EFI on a secondary install? I can't seem to be able to do that.

The setup is a triple boot machine using the heinous GRUB-EFI. Kubuntu is the primary install ("owns" GRUB) and Windows 10 and KDEneon are both in the menu.

For the Kubuntu install I have the familiar "Advanced Options for Ubuntu" line but for KDEneon - nada.

[claydoh]

Boot via neon via the system's boot selection hotkey? - this gets you Neon's grub, not Kubuntu's.
(or try efibootmgr's -n option -- the bootnext setting)
I have not multi-booted Neon and Kubuntu in some years now, and that's what I did to do this, I think.
Unless *buntu mucks with Neon's efi directories, that is. No one grub 'owns' things, just whichever boot loader is the first choice in the firmware setup's boot order.

[oshunluvr]

So to select a different kernel on KDEneon, I have to boot to BIOS, change the boot order, and reboot.

[sarcasm] Wow. Another great thing about UEFI. (rolls eyes) [/sarcasm]

Well, that doesn't seem correct. Neon is the first in the UEFI boot order, but the Kubuntu grub menu is what shows. Stupid.

IME the last installer that installs grub holds the grub files, thus "owns" grub. I'm seeing the Kubuntu grub because I installed it after Neon

[claydoh]

The usual f2/f10/f12/etc hotkey for your system doesn't offer a boot selection menu? My laptop uses f12

I was assuming that kubuntu's grub simply didn't or doesn't merge Neon's boot info into its menu. Like I said, it has been a long time since I ran both on the same machine. Each OS has its own bootloader executable (grub, windows' boot manager, or whatever), unless of course *buntu has effed with things. Not sure how Neon manages things compared to other derivatives like Mint or Pop. Ubuntu hard codes some paths in its grub, I believe, so I imagine those build their own grub packages. Neon does not, so perhaps this is the Achilles heel here.

Actually, Mint does do its own grub packaging.


Soooo...lemme see
https://chaselau.me/2019/01/repairing-kde-neon-grub/

methinks to get around this might be to rename the 'ubuntu' dir in the efi partiiton to something else (say, 'Kubuntu') and reinstall grub in Neon. Or...like in the link above, create a new ubuntu dir and copy the grub.cfg file from the Neon dir to the new ubuntu dir


If you look at the contents of the Neon grub.cfg on my system:

search.fs_uuid c2dc6e3f-67b0-4124-bd05-6dab50e41016 root 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

This is the exact same content as the one in my ubuntu dir, setting the root drive by its uuid


This of course will only probably only work (if it works) until Kubuntu gets a grub update.
Maybe?


This is just another one of those 'ubuntu sux' situations, or Neon could do better. I lean toward the former
If this were a non-ubuntu OS, you would not be having this issue.

ie blame ubuntu not efi

[oshunluvr]

I can think of several work-a-rounds including the one you suggest. Like using 40_custom to link to the Neon grub.cfg menu. Not the point of course, but you make several good ones as usual.

I had Manjaro on this laptop for awhile until I borked it and it's grub menu was quite sophisticated in comparison to any *buntu. Maybe I'll re-install it and let it's grub do the heavy lifting. I'm actually getting tired of the current state of Neon anyway. Too many things not working like they should. I may move to Kubuntu or something else all together.

I'm going to fiddle with this a bit more and see if I can make some sense out of it.

[claydoh]

I am thinking Neon should perhaps have waited for Ubuntu to actually enable bionic-focal upgrades before doing theirs. But then again, you can only wait for so long for them to get their s*** together.
I only had a minor sound card issue, which seems to be common for upgraders, and seemingly rampant with Neon users.

[oshunluvr]

So I tried the F12 thing and the results are the same. Only the Kubuntu grub menu is being accessed. I haven't done anything yet, but I'm wondering if it's the "$prefix/" that's the issue. That variable is not working or something. I wonder if it has to do with using btrfs and subvolumes. My two grub.cfg files in the EFI folder:

search.fs_uuid <uuid> root 
set prefix=($root)'/@neon/boot/grub'
configfile $prefix/grub.cfg

search.fs_uuid  <uuid> root 
set prefix=($root)'/@kubuntu/boot/grub'
configfile $prefix/grub.cfg

but both end up at @kubuntu/boot/grub/grub.cfg

I think ultimately it's use 40_custom to page to the neon menu. Now I really want to re-install manjaro to see if it's grub behaves the same or not.

[jlittle]

I've found lately that even if the EFI variable points to a .efi image in another directory, it still uses the grub.cfg in the EFI/ubuntu directory.

[oshunluvr]

I've found lately that even if the EFI variable points to a .efi image in another directory, it still uses the grub.cfg in the EFI/ubuntu directory.

Good to know John. That's EXACTLY what I'm seeing.DO you know if a bug has been files? I can search when I get a chance.

When I get back to that laptop, maybe I'll edit that file on the neon install and see if hard-coding the directory fixes it.

[mr_raider]

I've found lately that even if the EFI variable points to a .efi image in another directory, it still uses the grub.cfg in the EFI/ubuntu directory.

Long standing bug. It makes it problematic when multiple ubuntu derivatives are installed

Sent from my HD1905 using Tapatalk

[Qqmike]

First, I sincerely apologize for not having the time this takes at the moment -- swamped here with everything imaginable; frankly a bunch of sh*.
If this is what I think it is ...

I've found lately that even if the EFI variable points to a .efi image in another directory, it still uses the grub.cfg in the EFI/ubuntu directory.

Yes, but I've talked about this many times. Maybe one of you guys has the time to check this out. I've tested everything, btw, on MY systems. Start with my how-to here:

UEFI Simplified, a quicker version
https://www.kubuntuforums.net/showth...l=1#post379977

where you will find this:

Technical note Briefly: There is just one EFI subdirectory for Ubuntu-based OSs, /boot/efi/EFI/ubuntu. You can get around this by creating separate, clearly named subdirectories for Ubuntu-based OSs using -bootloader-id=some_name. Suppose you do this for Ubuntu-based LinuxX; thus, /boot/efi/EFI/<some_name_for_LinuxX> contains the GRUB files for LinuxX. Now boot from <some_name_for_LinuxX>. Instead of using the location of LinuxX's GRUB files pointed to by /boot/efi/EFI/<some_name_for_LinuxX>, the system may use the location pointed to by the default directory /boot/efi/EFI/ubuntu (by /boot/efi/EFI/ubuntu/grub.cfg). This happens because the location /boot/efi/EFI/ubuntu/grub.cfg is hard-coded into the GRUB executable grubx64.efi. (The location /boot/efi/EFI/ubuntu is populated by the MOST RECENT (K)Ubuntu-based OS installed (or from which grub-install (with no options) was run). To fix this, you must (1) disable secure booting in UEFI firmware, and (2) use --no-uefi-secure-boot in your grub-install command when setting up a dual-boot with Ubuntu-based OSs using separate EFI directories.

See lxgr's blog Booting multiple Ubuntu versions with EFI
http://blog.lxgr.net/posts/2015/04/3...efi-multiboot/

And I give several solutions to dual-booting that work around this technicality. This is not news. I wrote this 5 years ago. The key is a certain command that I talk about there. I used this on 14.04, 18.04, ASUS motherboard, I do not use NEON.

[Qqmike]

As I noticed, this is at least the 3rd time this issue has come up. I'm wondering if anyone is/has/will try the 'way around it'? (as outlined and linked in my how-to post above, or the lxgr's blog)

[oshunluvr]

I'll try that when I get time. Looks promising.

[Qqmike]

I do wish that you guys, jlittle and mr_raider, would try that workaround I posted. You are both UEFI experts, and this subject keeps coming up. The fix works for me; it goes back 5 yrs. And if you are too busy at this time, I can understand that, for sure. Of all things, and on top of everything else, lately I've undertaken to learn the Korean language, at my age. I hardly have time for a pizza anymore. It's like studying mathematics. But please try to keep it in mind. That solution works like a breeze for me.

[mr_raider]

I do wish that you guys, jlittle and mr_raider, would try that workaround I posted. You are both UEFI experts, and this subject keeps coming up. The fix works for me; it goes back 5 yrs. And if you are too busy at this time, I can understand that, for sure. Of all things, and on top of everything else, lately I've undertaken to learn the Korean language, at my age. I hardly have time for a pizza anymore. It's like studying mathematics. But please try to keep it in mind. That solution works like a breeze for me.

I only have one dual boot PC, and it uses windows/Neon on physically separate drives.

I guess if I were to ever install multiple ubuntu derivatives I would try it. Maybe in a VM or something.