![Mr Green :mrgreen:](./images/smilies/MRgreen.gif)
Linux Ubuntu 19.10 was released to the wilds about a week ago. This distro of Linux has always had the top spot on my list of favorites so that it was only natural for me to download it and test it out. I made a live USB version just to see what it looked like. The pre-release reviews said this was going to be the model for the LTS release coming in about six months. A lot of new features and improvements were included. It's just the kind of thing that gets my curiosity rolling in high gear.
I didn't expect it to go smoothly, to be honest. I've been jaded by all the negative, but enlightening, UEFI experience I've acquired lately. My expectations were not denied when I tried to install Eoan Ermine to my hard drive along side Windows 10. I've been running the previous version of Ubuntu in that slot and deleted it's partition to make room for the new guy in town. It was actually pretty simple until I got to the end of the installation. At that point the installer halted and issued an error message something to the effect that it could not install Grub into the EFI partition. I quit the installer and tried to boot just to see what the damage was, if any. All I got was the Grub shell prompt after selecting Ubuntu from the Windows boot manager. Previously, Ubuntu would load Grub and run, but since there was no Grub there was nothing to run with.
As you may recall, not only do I have Windows 10 on this hard drive, but I also have Kali Linux and Mageia, each of which have their own version of Grub inside their partition. Not only that, but I also now have rEFInd installed along with the Windows boot manager, and can boot to anything on that drive that way. So, the fact that Ubuntu didn't install Grub didn't stop me from loading it via a back door. It looked good at first and even updated Grub when I told it to. Rebooting, however, didn't change the options in the boot device selection menu. I still only got the Grub command line when selecting Ubuntu. While that was unfortunate, I figured it wasn't that big of a problem in that I can still boot using somebody else's bootloader. Well, yes, I could indeed boot, but some things simply didn't work. It did not complete installation when it issued the Grub error. It was like 98% complete, but that last 2% was missing critical files.
The question in these kind of situations is, "Is it me, or is it the software?" causing the problems. Being the clever person I now am, I mounted the system ESP partition, where all the UEFI boot files are located, and looked over what was in there. To my surprise Grub from Ubuntu was there. I didn't know if it was left over from the previous install or if the current Ubuntu actually put it there and lied to me about not being able to do it. To find out I had to dig up some specialized tools that would allow me to edit the Windows boot manager device selection menu. The goal was to delete the Ubuntu entry so that there would be no remains from a previous lifetime. Once you have the right tools, it's easy to do. So I did it. No more Ubuntu. I also deleted the Ubuntu partition again. Thus no traces of Ubuntu were on that hard drive.
Did the installation again and got the same results again. Grub was in fact installed where it's supposed to be, but the Ubuntu installer (which goes by the name Ubiquity) insisted it could not install Grub to the /target. Scratching my head I looked over the situation with Gparted and discovered that Ubiquity not only mounted the ESP partition but also the Ubuntu partition, which it labeled /target. So ... I was then wondering if it was trying to install Grub to the wrong partition. How in heck would I know that? Did you say go to the Ubuntu tech support forums? Regardless of your answer that is exactly what I did.
Well, I won't go into the details in any depth, but the Ubuntu support for this kind of problem is terrible compared to the same forum in Linux Mint. The moderator's answer was how to fix this problem with a workaround for installing Ubuntu onto a USB memory stick. I told him several times I'm not trying to do that, and he answered each time that is how he fixed his problem when making a removable copy of Ubuntu. Ugh! He did leave a comment that rang a bell, however.
First of all, Ubiquity is flawed. It only works when installing Ubuntu onto bare metal. It's does not work in dual, or in my case multi-boot, situations. Forget about anything that might be USB related. The references he cited for a similar problem go back to 2013 where people are bitching about the same symptoms I was seeing. The conclusion to be drawn is that the bug in the installer has existed for six freaking years and nothing has been done to fix it. In fact things were done to make it worse given that I'm getting the error message about installing Grub to the wrong partition. When I looked at the Grub script that Ubiquity installed in the correct ESP partition I noted something I've seen before when dealing with Ubuntu. The UUID for the partition was altered. Ubiquity did it. Obviously. I know I've reported this aggressive misbehavior before in this forum, and here it is again. With the wrong UUID, of course Ubuntu would not boot. There is no such drive as it is specifying.
It turns out that there is a way to run the installer without an attempt to install the bootloader, i.e., headless. I did that just be be certain that the installation completed even if there was no Grub. I don't need no stinking Grub now that I have rEFInd. Regardless, after the reinstall completed I rEFInd booted into it to prove it works. And it did. Then it was just a simple matter of going into the EFI partion Grub and replacing the erroneous UUID with the correct one. Now, I am back to normal. Ubuntu and all the other OS's boot as expected from within the Windows boot manager.
Blaming Windows for this catastrophe would be easy, but I proved to myself at least that Windows is innocent and doing what it does best: it just works. Ubuntu, on the other hand, can't even install itself properly because somebody hasn't fixed a six year old problem nor even recognizes a new problem where Ubiquity corrupts boot files on any system that is not it's own. This clearly boils down to the major issue I have with FOSS. The developers of Ubuntu took it upon themselves to modify the open source booting software to the point where it is useless. Why? Because they can. It's free and open.