Dual booting *buntu EFI installs???

[oshunluvr]

How does one configure dual booting when Ubuntu, Kubuntu, and who knows how many other flavors use "ubuntu" in the EFI directory for booting? Thanks goodness KDEneon finally moved away from using "ubuntu" in /efi

p.s. I still haven't moved away from legacy grub bios booting...

[GerardV]

I have Kubuntu 24.04, 24.10, Deepin 23 and MX 23 installed over 2 NVMe's. The PC setup will detect all entries in the EFI directories in both NVME's and give you a choice from which to boot first. In my case Kubuntu 24.04 which will then be the default when you turn on the PC. The Kubuntu grub will display all the installed entries from which to choose

[claydoh]

Neon definitely does use/have that /ubuntu/ dir. It is hard coded into Ubuntu's grub packaging and configuration
However, take a look inside and see what it's boot.cfg references. It should point to neon's /boot/grub/
Here is mine:

search.fs_uuid 63a67de9-25de-489a-b2d5-911658a1989e root
set prefix=($root)'/@/boot/grub'
configfile $prefix/grub.cfg

Note that the grub.cfg in /boot/efi/EFI/ubuntu/ is identical to the one in /boot/efi/EFI/neon/
I have no clue as to why or what it means, but all ubuntu based variants do the same thing neon does, while all official Flavours share the same layout/configuration.

All of neon's actual boot loader is in /boot/efi/EFI/neon/ dir. Other ubuntu-based distros do the same, unless they build their own grub packaging. I don't think any do.



Here is a fairly good description of the Ubuntu setup:
https://askubuntu.com/questions/1512...ed-on-the-same
A salient point it makes:

Most Linux distros nowadays are shipped with the GRUB bootloader. Technically, GRUB is also a boot manager (i.e. it can show a menu of options to the user when the computer starts).

Basically, with multiple Ubuntu Flavours installed, and using the same EFI partition, it is basically the same as an MBR setup: The Last Ubuntu Installed takes over grub duties, since they are all using the same exact directory and file structure. Anyone using the old skool MBR setup is probably familiar with this.


Now, with EFI, you can get around this by simply using multiple EFI partitions. You can have them on different drives, and even multiples on the same drive, as I understand it. Never done so myself, and Windows probably doesn't like it.

With dual drive setups, I use a separate EFI on each when dual booting, as it gives me a completely separate set of boot loader locations for fallback purposes. You just choose which one via your board's boot menu hotkey, or by setting your preferred boot order in the EFI firmware (aka BIOS) settings.


Clear as mud?

fwiw, things are similar with other distros with different 'spins', like Fedora if using grub iirc.
I am not sure if the new-ish systemd-boot (instead of grub) can also 'solve" this, but I haven't looked into that. Too much hackery, even for me.

[oshunluvr]

I have not had trouble dual booting Neon and (K)ubuntu so the /ubuntu folder does not seem to have a negative impact. Try to dual boot Kubuntu and Ubuntu is a different matter.

[GerardV]

Now, with EFI, you can get around this by simply using multiple EFI partitions. You can have them on different drives, and even multiples on the same drive, as I understand it. Never done so myself, and Windows probably doesn't like it.


.

And i have read of instances where Windows modified the EFI partition after an update and wipes all other entries in that partition. So if you want to dual boot with Windows i would recommend too, to use a different drive.

[Qqmike]

From various posts, it does seem Windows may complicate things. I'm not sure because I haven't tested anything with Windows. (I don't have a copy of any Windows anymore, although once was an XP (quasi-)expert.).

I don't know about all this. At one time, I ran bunches of Linux tests for dual-booting. It all worked!
But I have seen posts indicating that some people are having varying results trying to dual boot Ubuntu's.
Maybe it's their UEFI behaving peculiarly or not cooperating at all? Maybe their level of competence in setting things up? Maybe Windows goofs everything up?
It's detailed stuff. I have been left feeling that it's best to use 1 operating system per computer!! 😅

FWIW, Here's my last quick version:
https://www.kubuntuforums.net/forum/...820#post545820

======================
I used 5 methods for dual-booting, summarized in the Cheat Sheet as follows:

Dual-booting Kubuntu: A summary of 5 options
3 facts:
(1) GRUB from the last installed OS will take over the booting show.
(2) All Ubuntu-based distributions use the (same) directory name ubuntu in the ESP: /boot/efi/EFI/ubuntu; the last installed OS will overwrite previous /EFI/ubuntu contents. Other non-Ubuntu OSs have their own /EFI subdirectory.
(3) The last-installed OS or installed boot manager becomes first in UEFI BootOrder.
--> Fix this using either efibootmgr -o; or if GRUB, using sudo grub-install (and sudo update-grub).

5 methods for dual booting:
#1, #2, #3, do nothing special:
(1) Use rEFInd. (2) Use GRUB2-EFI. (3) Use the UEFI firmware.
Or, try #4 or #5:

(4) Ubuntu-based OSs: set up separate subdirectories of EFI: /boot/efi/EFI/<some_ubuntu_distribution>
Set up the dual-boot: Both LinuxX and LinuxY are Ubuntu derivatives, using the same ESP.
Disable Secure Boot in firmware. Install LinuxX, boot into it, then:
Code:
sudo grub-install --bootloader-id=<some_name_for_LinuxX> --no-uefi-secure-boot
Repeat with LinuxY. Optional: adjust BootOrder and generate new boot menus.

(5) Separate ESPs:
GParted: set up the ESPs and the OS partitions you need, give each ESP a label you will recognize. Install each OS, in sequence, with this procedure: Turn off all ESPs (turn off their boot flags) except for the ESP you wish to be used by the OS you are about to install now. Install the OS using the Manual installation method. Repeat for each OS. Then turn on all ESPs (re-set their boot flags in GParted).
======================

At the level of the NVRAM variables in UEFI lists, there is a matter of labels that one can play with.
Copied from that how-to:

Labels: Setting (and "changing") labels for UEFI Boot variables--useful for multiple "ubuntu" OSs

Fact: You can't edit or modify an existing boot entry. Instead, you must CREATE a new boot variable labeled whatever you wish. Then, if you wish, you can delete the old boot variable.
The setup: The UEFI boot variable BootXXXX uses ESP sdxn and the boot-loader file /EFI/<directory_current>/<boot_loader>. Goal: Change the label to NewLabel.
Solution
To create a new boot variable having the label NewLabel and pointing at the same ESP sdxn and same bootloader: /EFI/<directory_current>/<boot_loader>, boot (in UEFI mode) the OS (represented by BootXXXX). Issue the command:
Code:
sudo efibootmgr -c -d /dev/sdx -p n -L NewLabel -l \\EFI\\<directory_current>\\<boot_loader>
(This registers in UEFI firmware a NVRAM variable with Label L = NewLabel.)

To delete the old boot variable (having the old label):
Code:
sudo efibootmgr -b XXXX -B
--> This deletes only the listing of the variable in UEFI firmware. It does not delete anything in the ESP or in the Linux filesystem. The output of efibootmgr -v is identical for both the old and the new boot variables: they point at the same /EFI/<directory_current>/<boot_loader>.
Updating GRUB2-EFI: Getting an update to GRUB or running sudo grub-install (which updates <boot_loader>) in this OS will not break either the new or the old boot variable.
======================

I don't do this stuff anymore! If I ever did again dual boot, it would be with just two Linux OSs, even two Ubuntu's,
and for that small configuration, almost any method would work.
(Translation: You could learn to cope with it without too much stress.)

[claydoh]

But I have seen posts indicating that some people are having varying results trying to dual boot Ubuntu's.

Really, is isn't a problem per se, it is just that installing multiple Flavours ends up with the last installed one overwriting the files in /boot/efi, opposed to having individual boot loaders, as would be expected if they were two different distros.

Now, on a multi disk setup, with multiple efi partitions, what I think happens for some is that the Ubuntu#2 install is successful. BUT their boot order is still set to boot Ubuntu#1, which has zero knowledge of the new OS install. So they don't see the new Ubuntu#2 in its grub menu. Similar things could happen back in the olden MBR tymes, where you had your main Grub on the MBR, and your other distros with grub installed to a partition. And you forget where you were

To add to this, since Grub now recommends not having the os_prober enabled after the initial OS install, updating Grub on Ubuntu#1 never detects the new Ubuntu#2
And users might have no idea that there are even multiple boot loaders involved, let alone no os-prober action, or that there is even a hardware boot menu to use to get do a different OS.

[Qqmike]

claydoh

And you forget where you were

I think that hits the nail on the head. In general, with the Ubuntu's people don't know where they are or where they were!
Running efibootmgr, you get multiple listings of "ubuntu," which doesn't help (unless you don't mind deciphering the GUIDs/UUIDs).
That's where the business of "labeling" comes into play, that I mentioned in the how-to, but that takes some effort and focus.

[oshunluvr]

Funny thing is I do have a Windows install on my PC and it's UEFI lol. My BIOS lets me boot either EFI or Legacy mode. I only installed it to try and run a NVME firmware update that came packaged for Windows. I've only booted it twice. Of course the P.O.S. firmware updater didn't work. TIP: Don't buy Adata products.

Claydoh's and Qqmike's posts do a could job validating my complaint. Could it be more complicated? It's almost like we finally got GRUB working well and the uber-nerds decided we can't have it that easy. That's why I haven't switched to UEFI. Why? Full disclosure, I stuck with LILO for a couple years after GRUB came out, LOL. Maybe it's me

[claydoh]

I actually find GPT and efi booting simpler for me to understand, once I started using it, outside of Ubuntu shenanigans with grub. I also find it robust, from my own personal experience. I did wait a bit before moving over myself, since I understood MBR and multibooting fairly well, from experience mucking it up, lol.

I am going to look at systemd-boot at some point, which is quite sparse visually, but seems a LOT simpler to use and manage, even if one sets up things manually. It may may not be very useful everywhere as kernels get put in the EFI partiton, so it needs to be much larger, and I think that Debian/apt can't or won't install things to a FAT file system at all, so kernel installs take extra steps, because of course Debian/Ubuntu have to be just a bit weird.

[Qqmike]

I actually find GPT and efi booting simpler for me to understand,

I agree. I do, too, find it conceptually easier to understand ... except for that Ubuntu thing (for which there are (inconvenient) manual workarounds ...)
UEFI with mouse and keyboard navigation. The convenient efibootmgr command. Plusses.

I had difficulty going from GRUB legacy to GRUB-2 because of having to understand scripting of the menu entries.
Wasn't going to go back to my programming days. And so just accepted whatever menu entries were dropped into my GRUB folder.
I kinda lost interest at that point. Too slick.

[claydoh]

I haven't edited a menu entry in a dog's age. Too much work. So is dual booting - more OSs to install is an excuse to get more kit

[Qqmike]

I haven't edited a menu entry in a dog's age. Too much work.

Ha! Same here. Sometimes, I forget even where the GRUB config files are, but I have all that stuff written down in my Cheat Sheets.

[oshunluvr]

So if your EFI gets borked, can you boot from a console like you can with GRUB?

[Qqmike]

What scenarios are you thinking of?

I clipped this from my how-to, most/all of it you know or know about.
Using Your Live Kubuntu DVD/USB to Fix Things
https://www.kubuntuforums.net/forum/...401#post545401

Note the use of rEFInd and that it can be put on a flash drive from your live Kubuntu session.
I keep a copy here; in fact, reminds me to update that rEFInd flasher.

Fix booting problems when you can't boot into your OS
Fixing the GRUB bootloader. Using Boot Repair. Getting rEFInd. Using chroot.

When you have a problem booting into an OS, you might be able to easily fix the problem if you could get booted into that OS. Thus, the goal is to either fix the problem from outside the OS (from your live Kubuntu session) or use your live Kubuntu session to help you get booted into the broken OS (where then you can fix the problem). So, thinking this through now ...

You can fix GRUB from your live Kubuntu session.

This may involve re-installing GRUB (to the broken OS), and/or fixing a configuration file, and/or regenerating a new GRUB boot configuration file (/boot/grub/grub.cfg).
Do you have an Internet connection in your live session?
Getting Boot Repair and rEFInd requires an Internet connection in your live Kubuntu session. Using chroot to fix GRUB manually does not require an Internet connection. (Of course, if you already have Boot Repair and rEFInd CD/USBs, then no Internet connection is required.)

Boot Repair: re-install GRUB
The easy way would be to use Boot Repair, which will re-install GRUB for you (and do other things, if you like). You can install Boot Repair in your live Kubuntu session and run it from there.

rEFInd: it will boot you into your OS
For newer systems (say after 2011) using UEFI booting, with GPT partition scheme, rEFInd is a boot manager that can get you booted into your OS, even if your GRUB bootloader is not working. The problem is, you must install it from your OS. Or, use a rEFInd CD or USB flash drive. Fortunately, you can make a rEFInd CD or USB flash drive in your live Kubuntu session, then re-boot using it, and from the rEFInd boot menu you will select what you wish to boot. After booting into your installed (broken) Kubuntu OS, you can repair GRUB yourself with two commands:
sudo grub-install
sudo update-grub
And/or, after using rEFInd to boot into your installed Kubuntu OS, you can then install rEFInd to your computer from within Kubuntu. (rEFInd and GRUB will not interfere with each other, they can work alongside each other.)

Fix things manually using chroot
From your live Kubuntu session, you can use the powerful command chroot to work on your installed (broken) Kubuntu OS; in particular, you can re-install GRUB and generate a new GRUB boot file (/boot/grub/grub.cfg). This option is for people who feel comfortable working at the command line as root, and working on their system; there are plenty of step-by-step how-to's on it. It is simple, but you do need to pay attention as you work. Using chroot, you can run the two commands for fixing GRUB: sudo grub-install and sudo update-grub.

What else ... ? You could also make a back-up (on flash drive) of your key EFI files, /boot/efi/EFI/ubuntu/.... Do so just by copy-paste or dragging.
So, if push came to shove, you could copy into EFI building it from scratch. I have done that (in the distant past).
If you are booted into your Kubuntu (say, by rEFInd), you could re-make the ESP if it got totally deleted (KDE partition manager or gparted; and then try
sudo grub-install
sudo update-grub
and see if that worked to populate anew your ESP (boot/efi/EFI/ubuntu/...)

Just trying to think of what "borked" could include.

[claydoh]

Some boards have an EFI console where you can manually create a boot option option by specifying a particular boot loader file

But for clarity:
The EFI partition is still just a portition. Think of it as a large MBR, and not on a hidden portion of a drive, and can hold many different boot loaders. Maybe types of distros even put kernels there. So you'd still be using a Grub console or whatever is used for the propose by whichever OS' bootloader is borked.

The firmware boot options on UEFI accessed via an f-key are based on the individual boot loaders found in that partition.

The boot order settings in the firmware UI (formerly called a BIOS, but I and most people still call it that) is just selecting which boot loader to use first.

If it's a Linux distro, it loads that distro's Grub or whatever boot system it uses, which includes a boot menu.

So, if you have Windows, Fedora, Kubuntu, Mint and Arch installed you'd have at least two different Grub menus available, and possibly up to two using systemd-boot, with a total of four different boot menus with entries for whatever items they were last configured to have.


That's how I think I understand it, and is probably over simplified. Possibly wrong, even. I didn't even bing it, or read that Wikipedia page
I just woke up and and it's cold so my brane might be thawing still.