Still not using UEFI. Should I?

[oshunluvr]

I went to KDEneon in 2018 but thinking I might transition back to Kubuntu. While I'm re-configuring everything, I thought about UEFI and if there's any real reason to use it. I have avoided it successfully for many, many years. Why? Initially the release of UEFI was tied to MS and dual booting was problematic. So I just stuck to GRUB.

Current setup: I have 4 bootable installs. One of those is an Ubuntu server install (no graphics) that only serves as a GRUB host. It boots to a custom grub menu. From there, I select my chosen distro, and it switches to the grub.cfg of one of the other 3 installs. Then it boots the selected distro. I doubt it matters, but all the distros are in BTRFS subvolumes on the same BTRFS file system. This was set up in 2018 or so.

Reasoning: I went with this design after having GRUB wiped out in the past by subsequent installs or removing the distro that had last installed GRUB leaving my system unbootable. Now, when I do a bare-metal installation of a new distro, I point it's GRUB install to a partition rather than the boot drive. This allows each distro to create it's own GRUB config but insures the bootable version of GRUB is untouched.

The downside: I have to manually edit GRUB menu of the GRUB host distro and update GRUB before booting to a new install. Not really an onerous task, but still a task. Also, since this approach results in two grub menus at boot time, there is an additional timer delay at boot time unless I hit Enter twice. Again, not a huge problem, but it's there. I have all GRUB timeouts set to 5 seconds to minimize the delay.

The reason to change: Moving to a single boot manager that doesn't need as much manual maintenance would be nice, as well as a single boot screen instead of two.

The questions:

1. Should I change to UEFI and why?
2. Can UEFI even allow this?
3. How would UEFI handle multiple new installs without messing with other existing installations?

I have run into problems in the past on my laptop, which is using UEFI, when I had Kubuntu installed and then installed KDEneon. At the time, both distros using the same UEFI folder so installing KDEneon resulted in Kubuntu not being displayed in the boot menu. I think KDEneon fixed this, but I could see this happening again somewhere in the future, like installing a newer version of a distro along side an older version. TO be fair, I probably wouldn't do that because I typically us VMs for short term testing.

[Qqmike]

I think the way you're doing it now involves a fair amount of details, like grub boot partition, chainloading, and protecting the main GRUB menu.
Without having run such a system as you use, on a daily basis, it's difficult to picture the nuances and details with UEFI vs GRUB.
Maybe it could end up being six of one, half a dozen of the other.

But maybe with UEFI, it might be conceptually slicker, cleaner;
and maybe the bang for the effort might be bigger and better, a better cost-benefit profile.

With UEFI, you do have the option of booting through the firmware Boot menu(s).

With UEFI, you would have the option of using Rod Smith's very helpful, clean boot manager rEFInd.

With UEFI, you do have configuration options, although, as with GRUB, they require manual setups.
Like using multiple ESPs.
Like creating different folders in your ESP (/boot/efi/EFI/[folder_name]) for different OSs.

With UEFI, you do have the function efibootmgr for changing the boot order, for example.
Where, efibootmgr runs in a Kubuntu console.

And rEFInd can exist alongside other booting options you may have.
You can specify that the system is to boot first from reEFInd, if you wish;
but, again, you can always access firmware UEFI-BIOS Boot menu(s) and override that as you wish.

Now, as I know you know, regarding Ubuntus, if you install a new one, it will overwrite what is in the stock ubuntu folder, /boot/efi/EFI/ubuntu.
But you could install a new ubuntu into some other ESP or some other ESP folder so you would have an avenue of separately accessing that new ubuntu OS.

And I know you know I have how-to(s) on options for multi-booting.
I'm rusty on it, as I only experiment once in a blue moon nowadays, but it's not hard to review or to read through
I tested, I think, about every configuration I could think of (multiple Linux OSs vs multiple disks),
but I have zero experience running a server, for example.

Don't know if any of this strikes a chord!

[die.boer]

this is a straight up AI answer ... as i'm not positive about an answer , but what from what i see the AI seems to nail it ?

The short answer is: yes, I would move to UEFI, but not because it magically solves GRUB problems. Rather, it gives you a cleaner, more resilient boot architecture.

A few points about your current setup.

Your BIOS/legacy setup is actually quite elegant. By dedicating one installation to being the "GRUB host," you've isolated yourself from one of the classic problems of legacy BIOS installs: whichever OS last writes to the MBR owns the machine. Your solution avoids that completely.

The fact that you've been running it successfully since 2018 says it's a good design.

Where UEFI differs is that there is no single boot sector to overwrite. Legacy BIOS

MBR
└── GRUB Stage 1
└── Ubuntu Server GRUB
└── chainload Kubuntu GRUB
└── chainload Neon GRUB
└── chainload Fedora GRUB


One damaged MBR and nothing boots.

---

UEFI


Instead you get something like
UEFI Firmware

├── Kubuntu
│ EFI/kubuntu/shimx64.efi
│
├── KDE neon
│ EFI/neon/shimx64.efi
│
├── Fedora
│ EFI/fedora/shimx64.efi
│
└── Ubuntu Server
EFI/ubuntu/shimx64.efi


Each distro has its own EFI executable.

Deleting Kubuntu does not remove Fedora's loader.

Installing Fedora does not overwrite Kubuntu's loader.

The firmware simply maintains a list of boot entries.

---

Does UEFI eliminate GRUB?


No.

GRUB is still there.

UEFI simply loads GRUB differently.

Think of it as
UEFI
↓
GRUB
↓
Linux


instead of
MBR
↓
GRUB
↓
Linux

---

Your concern about one distro overwriting another


This is a real issue—but it isn't really a UEFI issue.

It's because Ubuntu derivatives historically all installed into
EFI/ubuntu/


So

• Ubuntu
• Kubuntu
• Xubuntu
• Lubuntu
• KDE neon

all used
EFI/ubuntu/


Meaning installing one replaced the files from another.

That was annoying.

Nowadays it's less of an issue because:

• installers are generally better behaved,
• many distributions use unique directory names,
• even if they share EFI/ubuntu, the installed GRUB usually just boots whichever root filesystem it was generated from.

It's still one of the weaker parts of the Ubuntu ecosystem, though.

Fedora, openSUSE, Arch, Debian, etc. all use separate EFI directories.

---

What happens with multiple installs?


Much better than BIOS.

Suppose you install

• Kubuntu
• Fedora
• openSUSE
• Debian

Your firmware menu simply becomes
Boot0000 Kubuntu
Boot0001 Fedora
Boot0002 openSUSE
Boot0003 Debian


Each is independent.

Removing one OS doesn't affect the others except leaving behind an unused boot entry that you can remove later.

---

Could you still have a "master" bootloader?


Absolutely.

You could install GRUB on one distro exactly as you do today.

Except instead of living in the MBR it lives in
EFI/ubuntu/


(or another EFI directory)

It can still boot every other distro.

The difference is:

If you accidentally remove it...

...your firmware can still boot one of the other GRUB installations directly.

You're no longer depending on one fragile MBR.

---

Even better: use the firmware directly


One thing many long-time BIOS users don't realize is that UEFI already is a boot manager.

Instead of chainloading GRUBs you can simply select
Kubuntu

Fedora

Neon

Ubuntu Server


from the firmware menu.

Or use a boot manager like:

• rEFInd
• systemd-boot (if your distributions support it)

Both automatically discover installed kernels with very little maintenance.

---

Would I recommend changing?


Given your setup:

Reasons to switch

• no MBR to worry about
• every OS has an independent bootloader
• firmware already keeps a boot menu
• easier recovery after removing an OS
• generally the direction Linux distributions are developed and tested today

Reasons to stay

• your current system is proven
• you clearly understand how it works
• it gives you complete control
• you only have minor inconveniences (double menu and manual updates)

---

My recommendation


If you're already planning a fresh migration back to Kubuntu, I'd take the opportunity to move to UEFI.

I probably wouldn't recreate the two-stage GRUB design unless you particularly enjoy the control it provides. Instead, I'd either:

1. Let one Kubuntu installation own the GRUB menu and use os-prober (or manual entries) to boot the others, or
2. Use a dedicated UEFI boot manager like rEFInd, which automatically detects multiple Linux installations and kernels and largely eliminates the need to maintain GRUB menus by hand.

With UEFI, even if one bootloader becomes misconfigured, the firmware can usually boot another installed bootloader directly, making recovery much simpler than in the old BIOS/MBR world. That's the biggest practical advantage for someone who regularly installs, removes, and experiments with multiple Linux distributions.

[oshunluvr]

Well, none of my drives are MBR, they're all GPT. Legacy GRUB installs just fine on GPT if you have a "bios-boot" partition, which I do on all my drives.

I have also installed GRUB on more than one drive so in theory I could simply change the boot device in BIOS and be able to boot to a backup device (although probably not as simply as I make it sound).

Having thought about it for a bit, I kinda feel like eventually BIOS-BOOT will go away and UEFI will be the only option for a new install and that's what's driving the above questions. Another potential concern is hardware change in the future (I tend to upgrade every decade or so) where the new mobo will no longer support legacy booting.

Again, having put a little more thought into it, I could probably let new installs use one of the other four (yes, that's right, 5 total, LOL) drives as it's boot drive while while using my primary drive for the multi-boot drive. Thus letting me boot to almost any drive in the event of an issue.

Thanks to both of you for the thoughtful replies!

I have some thinking to do. Luckily, there's no rush as nothing is giving indications of failure. There's also the possibility that I'll stop mucking about with other installs and just settle down on Kubuntu - but jumping around can be kind of interesting!.

[Qqmike]

(Just read your new post, as well as die.boer's post)

Just to add a technical note:

Installing more than one Ubuntu-based OS:

If you wish to create separate folders for two OSs, X and Y, as far as I know, you must use a special command:

sudo grub-install --target=x86_64-efi --efi-directory=DIR --bootloader-id=some_name --no-uefi-secure-boot

and, thus, you can only do this if secure boot is turned OFF.

(The how-to below includes this discussion: " ... the location /boot/efi/EFI/ubuntu/grub.cfg is hard-coded into the GRUB executable grubx64.efi."
And, thus, the use of that general grub-install command (above). to by-pass this restriction.)

*** I don't know what happens with a system containing Windows and so secure boot. Might have to think about that, or just try something and see if/how it works. ***

This how-to:
UEFI Simplified, a quicker version

https://www.kubuntuforums.net/forum/...l=1#post545820

contains 5 ways to dual-boot two OSs, including two Ubuntu-based OSs.

List of topics, in sequential order

UEFI+MBR replaces BIOS+MBR
Installing the OS in UEFI mode, doing your own partitioning, include ESP
How will you know you are booting in UEFI mode?
How UEFI booting works
ESP -- EFI System Partition
GPT -- GUID Partition Table
Two important commands: sudo gdisk and sudo efibootmgr
GRUB2-EFI, grub-install
rEFInd boot manager: recommended
Dual-booting with Kubuntu and GRUB2-EFI
Dual-booting: Summary of 5 options
Separate EFI directories for your OSs
Using more than one ESP
Changing labels on UEFI Boot entries: sudo efibootmgr -L
Fixing things: GRUB, booting issues, GPT, files
Cheat Sheet

[oshunluvr]

OK, thanks. NO Windows here (other than in a VM where I can contain it, LOL) and secure boot off. Again tho, worried I might be forced into secure boot down the road. Time will tell I guess..

[Qqmike]

With secure boot on, there are still other options for dual booting two or more Ubuntu distros that do not require that technical note I just posted.

[claydoh]

So

• Ubuntu
• Kubuntu
• Xubuntu
• Lubuntu
• KDE neon

all used
EFI/ubuntu/


Meaning installing one replaced the files from another.

This is not correct for KDE neon, at least in usage. While all *buntu based distros do have EFI/ubuntu/, distros like neon and Mint are all are configured to use a different place in addition to this directory for things. So overwriting EFI/ubuntu/ does not have an effect on these non-official derivatives.

I have never had an issue dual booting Kubuntu and neon using the same EFI partition.

But official *buntu all use the exact same grub, and do overwrite each other when installing. That is quite true.

Another addition/complication/good thing is that each drive can have its own EFI, though it is not necessary. Seems a safe option to me. I usually do this when two drives are involved.
(Technically one can have multiple EFIs on the same drive, but in practice, it never worked for me everywhere. It seems firmware-specific.)


Now, for my opinion, your BIOS/MBR setup in a strong sense is replicating what the EFI layout does.

Not sure if it is more work or not, but for me it has been almost completely install-and-forget, with zero time spent configuring grub when adding a new OS. Other than changing boot order in the firmware (bios) settings, maybe.

But for multi-booting, since each one has its own boot loader, these won't see a new OS install until you update grub in each, or get a new kernel, and also have os-prober enabled. Not usually a thing to worry about if your main Grub sees all the other OS installs, and one can always use the firmware (bios) boot menu to select a different OS as an option or backup.

I also think it is possible that using Legacy Bios mode may be disabling some hardware options or features, *maybe*. These may not matter. Resizable bar (Above 4G Decoding) is a big one unless you are using an older GPU such as an rx580. Pretty much most GPUs with 4 numbers in the name iirc really benefit from this feature. Though it may only be gaming or heavy graphics work where this would be noticed, probably. I am sure ther are other hardware options that might be missing in Legacy mode.

Also not needing to do any funky drive partitioning and limits if you are using the MBR scheme.


So, imo it is simpler, easier, more robust....but if you really have no issue, then there is no reason to switch or migrate. But starting from scratch, EFI is kind of a no-brainer.

[oshunluvr]

I'm not sure where all the discussion about MBR came from unless it;s being used to mean something different than the older style partitioning scheme. I haven't had an MBR partitioned drive in more than a decade. GRUB doesn't require MBR and - according to the specifications - neither does UEFI. GRUB works fine with GPT and GPT has several obvious advantages over MBR.

Regardless, thanks everyone, for the input. At this point, the likelihood that one install may overwrite the EFI folder of another seems like a deal breaker for anyone multi-booting the way I do. Probably best for me if I just stick it out the way things are with GRUB until I don't need it any longer or can't. I reviewed a few of the available alternate boot managers but they mostly seem like just pretty faces and not really making things easier.

[kubicle]

I'm not sure where all the discussion about MBR came from unless it;s being used to mean something different than the older style partitioning scheme.

msdos partitioning (older) and Master boot record (MBR) are two different things. To my knowledge, legacy bios boot still uses MBR for initial grub loading even on GPT partitioned drives, I might be wrong though, it's been ages since I've tinkered with those (moved to efi fairly quickly)

[oshunluvr]

msdos partitioning (older) and Master boot record (MBR) are two different things. To my knowledge, legacy bios boot still uses MBR for initial grub loading even on GPT partitioned drives, I might be wrong though, it's been ages since I've tinkered with those (moved to efi fairly quickly)

libparted supports 10 different partition types but most are old and out of use, The two in question (from gparted docs):

• gpt provides support for GUID partition tables
• msdos provides support for DOS-style MBR partition tables

So "g" in "gpt" = GUID and "m" in "MBR" equals "msdos". I always equated MBR and msdos partitioning as the same thing. Honestly, it's not clear what actually means what and I'm not convinced calling "MBR" and "msdos partitioning" "two different things" is accurate as one requires the other.

I also don't see how this equates to calling my setup MBR because it's not using msdos partitioning - thus my confusion with the above posts. I suppose it's a question of semantics, but from my view, inaccurate because I am not using msdos partition tables, thus not MBR. I'm using GPT partitioning with the needed BIOS boot partition for the GRUB boot loader.

If you use GPT, you must have either an EFI system partition (EF00) or a BIOS boot partition (EF02). GRUB will not install in legacy mode without the EF02 partition. GRUB needs the extra space for it's boot loader code because the GPT partition table takes the space GRUB used to use with MBR - so not MBR.

I feel a more accurate description is I'm booting via "Legacy GRUB" (vs. MBR) rather than "EFI GRUB"

Anyway - done with the hair splitting, LOL

[claydoh]

I'm not sure where all the discussion about MBR came from unless it;s being used to mean something different than the older style partitioning scheme. I haven't had an MBR partitioned drive in more than a decade. GRUB doesn't require MBR and

That was me ASSuming since, the two sort of go together. Went together. And I have too much cruft in my brain.

So ignore all that, it doesn't change anything related to legacy vs efi.

legacy bios boot still uses MBR for initial grub loading even on GPT partitioned drives

\
I believe this is correct. This is also why some installers (calamares) leave a few Mb free at the start of the drive on legacy boots, as iirc things are too big to fit on an mbr nowdays. I think.


Anyway, I shuts my yap now.

[kubicle]

libparted supports 10 different partition types but most are old and out of use, The two in question (from gparted docs):
I'm not convinced calling "MBR" and "msdos partitioning" "two different things" is accurate as one requires the other.

Not necessarily:
https://superuser.com/questions/1165...rtitioned-disk

Your setup is the second one: "In this variant, the first stage of GRUB still resides in the MBR"

[Qqmike]

Boy, the terminology gets overwhelming!

But I see two statements I personally can relate to:

oshunlvr:
If you use GPT, you must have either an EFI system partition (EF00) or a BIOS boot partition (EF02).
GRUB will not install in legacy mode without the EF02 partition.
GRUB needs the extra space for it's boot loader code because the GPT partition table takes the space GRUB used to use with MBR - so not MBR.

kubicle:
Your setup is the second one: "In this variant, the first stage of GRUB still resides in the MBR"
And the link you posted is quite technical but it's great, IMO.

[oshunluvr]

That link kubicle posted does a great job of explain it. Thanks!