I don't know why the developers of the various Ubuntu derivatives don't make the change (not using the directory name ubuntu on the EFI partition) if it is pure laziness or some other factor. I've seen posts here explaining how to do it during an install and it doesn't seem complicated. The solution to this is to not use Ubuntu AND its derivatives until it is changes. UEFI is much simpler than the older Legacy since a default install of most any system (windows or Linux) would overwrite the MBR boot code. With Linux you would get a choice but many would not notice or understand it. Installing windows in a Legacy system would overwrite any boot code in the MBR and the user would not be given a choice and would not be informed that it would happen. UEFI gives the advantage if used properly to boot an OS from the one time boot key from the BIOS on boot even with systems on the same hard drive.

1 members found this post helpful.

I can see how it would scare newbies and while not engineer level (I was analyst and builder) it has been brutal on me and if I were just a new ubuntu linux user and saw ooh a new shiny linux mint or other family and gave it a go with a hard install side-by and wound up unbootable I would be like never going to try that again. My plan is to just replace kubuntu with linux mint. Data is backed up, I will see how much settings I can save elsewhere and just overwrite kubuntu since mint will overwrite the boot files anyway. And yes, it can be done, I was doing it but too fragile and much too complicated to repair when the house of cards crumble from say an update/upgrade. Canonical is driving away users who can't install tryout another flavour without boot disaster.

There is a trick to keep linux mint or Kubuntu from overwriting the bootloader, and have grub installed when all is said and done.

You told me about unmounting the partition when it gets to the point of writing to it, right? In my case, not much point to it and having to repair. Kubuntu sits on the largest partition I have on the internal SSD. If I installed mint (heir apparent at this point) next to it again (which I did manage to fix with help last time), I would end up with my new daily driver sitting on a partition too small for my needs. I could resize, etc. But for me it isn't worth the boot repair trauma since I won't be continuing with Kubuntu. Possible to do, it is. But I got better things to do, like configuring shiny new themes and useless cool widgets.

It's simple enough to apply an admin solution, preferably on first boot following installation so as not forgotten: edit /etc/default/grub's GRUB_DISTRIBUTOR= line, as seen in thread post #1 here for Manjaro, to produce a unique string as the applicable directory name in /boot/efi/EFI/, e.g. kubuntu20 or neon22test or mint232. This way no installation overwrites another's ESP entry.

1 members found this post helpful.

Don't see how Canonical is responsible for what other developers do when allowed to use the ubuntu name and their repositories. Some Ubuntu derivatives don't use 'ubuntu' as a directory name so why do other do it and it should not really be that difficult.

I think that given current circumstances, the simplest way to avoid this problem is to only use one Ubuntu and/or one derivative on the same computer or at least the same hard drive. For purposes of testing, use a 'live' usb or virtual software.

Another way to avoid this problem when trying to use multiple ubuntu's on the same machine is to copy the 'ubuntu' directory for that particular OS to another location when installing the 2nd 'ubuntu'. Then if you want the original OS to be the primary bootloader, you simply copy it back to the EFI partition. You can easily create an entry for the 2nd OS in the EFI partition so you can boot from the BIOS. If you have a second hard drive, disconnect the first with the 'ubuntu' OS on it while installing the 2nd.

Of course, this could all be avoided if the Ubuntu derivative OS's would simply use a different directory name for their OS. I suppose Canonical could notify their derivatives that they are no longer allowed to use the 'ubuntu' name in this way but it seems the first method would be simpler and less problematic.

GRUB_DISTRIBUTOR= determines the applicable ESP directory name. It's a simple edit that will avoid the issue. There's no need for copying or switching anything else.

1 members found this post helpful.

The doesn't always work with ubuntu spinoffs. Yes it will create a separate esp name most times, however the bootloader in the named esp will still reference the ubuntu esp name for the grub.cfg file.
The work around I use, when 'file copy' starts open a termina\console unmount the esp partition.
When the grub-install error appears go back to terminal, chroot into the install directory, mount the efi partition, edit /etc/default/grub and install grub with this:

Yes, when multi-booting there are easier ways to keep/give desired distro control of bootloader,

1 members found this post helpful.

Well I know enough that although I am using kubuntu, it is an official flavour of ubuntu and therefore a canonical product, right? I tried Linux mint that is a little trickier in regards to "responsible party". But I am pretty sure I would run into same issue if I had laid down ubuntu next to kubuntu. But maybe not. I had neon on there which is not canonical and from what I saw called itself neon in EFI but colorpurple said there was another place it was overwriting?

But this issue may not be confined to buntu family. I have now added a straight-up real debian bookworm install to the mix. I have tested a derivative of debian recently but I removed (I can't remember if it was Watt or Bunsen) that identified itself as "debian" in EFI. Not sure whether I like the XFCE on debian I am trying out and was toying with a separate install of KDE debian next to XFCE debian rather than just adding a second DE to current install. Would I run into a problem or not? It is something maybe that should be brought up to devs of any distro in light of EFI becoming the norm and the amount of issues novices (especially) can run into and not be prepared for. And for $$$ linux distros if they offering different flavors why would they want to drive customers away from giving an additional install of a different version a try? Seems like something that can be "cut off at the pass" by the devs whether it be the original one or the ones spinning off of another. Perhaps not enough users are complaining. They just have a bad experience and say "not doing that again" and may never try out another product of said distro fearing "losing" what they had in place already and not knowing how to get it back.

I am not a distro hopper but I definitely like to window shop and try things out. Occasionally I come to a parting of the ways with a distro used for years and have to shop around. Others' mileage may vary.

Please elaborate. How does the spinoff know the actual directory name Ubuntu uses, when due to the unique value given it by its admin in its GRUB_DISTRIBUTOR=, and fully applied, is something entirely different? Is the spinoff actually going to dig into the installed system(s)' /etc/default/grub(s) or the ESP's EFI subdirs to decide what it/they should do when the Ubuntu(s) do not put the directory name ubuntu on the ESP anywhere?

Anyway, all this complication is needless. Install the first distro to include Grub. Install subseqent distros sans bootloader, or purge bootloader post-installation, or don't even install a distro that insists. Only one Gnu/Linux bootloader is needed per Gnu/Linux computer. Multiple bootloaders constitute complexity. My distro count per PC averages well over a dozen, ranging to somewhere above 40. It only takes one to get the job done. KISS.

This begs the question why more than a rare few would need both Ubuntu and any of its derivatives on the same computer, who do not have the experience to deal with this without help.

Actually all of the spinoffs that install or require NO software that is not in the UBUNTU repos, and is just a special set of configurations and defaults that you can achieve by installing Ubuntu and manually configuring for yourself, ARE Ubuntu! They are just a special SPIN of Ubuntu. That might confuse some people, be the Debian community has the same issue. (So does ARCH by the way) Until you actually make enough changes so that you must maintain a different REPO system and maintain software NOT in the parent, you just have a spin.

No disrespect to a good spin, the Ubuntu based spin of Mint is killer good! Manjaro is about one step away form being an Arch spin, and is killer good! It may be a bad idea (and cause problems that you cannot predict) to make the changes discussed BEFORE you divorce the spin form that parent distribution!

For example with linuxmint, there is a /etc/default/grub.d/50_linuxmint.cfg that sets the GRUB_DISTRIBUTOR= to ubuntu which forces grub-install to create and install to EFI/ubuntu directory. When the the GRUB_DISTRIBUTOR=ubuntu is commented out grub-install creates and installs to EFI/linuxmint, however without EFI/ubuntu/grub.cfg to set the prefix to the root directory no grub menu only a grub prompt at boot up.

Neon during installation creates two directories with grub-install EFI/neon EFI/ubuntu, without the EFI/ubuntu/grub.cfg same result a grub prompt.

This use of EFI/ubuntu directory as the default is a short coming of ubuntu based distros to allow booting with secure-boot enabled and used as well when secure boot in disabled.

Yes my method of fixing the problem at installation is convoluted and requires secure-boot to be disabled but it works if one wants more than one installed ubuntu distro to have their own efi bootloader

I agree, when mutlibooting: use only one distro to control the booting, know of ways to prevent other distro's from installing a bootloader, and know how to fix when things go wrong.

Not much point in installing multiple Ubuntu derivatives. Other options pointed out are just adding the different Desktop to the primary install, using a 'live' DVD/USB to test, using virtual software or possibly installing to a secondary/external drive. That last one is complicated by the Ubuntu installer with EFI as one would need to disable or disconnect other drives. Also, when the purpose is simply to test another distro, moving the 'ubuntu' directory from the EFI partition is a simple solution, moving it back later is also.

If that overrides an admin GRUB_DISTRIBUTOR= setting in /etc/default/grub, that must be a bug or an admin customization, or new in 21.3, or gone by 21.2. On 21.2 I just did apt-get install -d grub-efi-amd64 grub2-common grub2-theme-mint, which got me:There is no /etc/default/grub.d/50_linuxmint.cfg in any of those packages.

I did a fresh install of linuxmint in a vm and the 50_linuxmint.cfg was there in /etc/default/grub.d. I didn’t investigate what package it came from. I did lots of testing in a vm multi-booting various Ubuntu based distributions before answering this thread. A quirk I came across with kubuntu is when the —bootloader-id=kubuntu is used if kubuntu isn’t all uppercase it will revert to ubuntu. It may be the first three letters that have to be uppercase, I don’t remember if I tested or not.