19.10 new installation error: The 'grub-efi-amd64-signed' package failed to install

[Yogi2]

MY CONFIGURATION:
OS Name Microsoft Windows 10 Pro
Version 10.0.19008 Build 19008
System Name MSI
System Model GL72 7QF
System Type x64-based PC
Processor Intel(R) Core(TM) i7-7700HQ CPU
BIOS Version/Date American Megatrends Inc. E1795IMS.311, 2/22/2018
BIOS Mode UEFI
BaseBoard Manufacturer Micro-Star International Co., Ltd.
BaseBoard Product MS-1795
BaseBoard Version REV:1.0
Secure Boot State Off
Boot Device \Device\HarddiskVolume2
Installed Physical Memory (RAM) 16.0 GB
Total Virtual Memory 18.3 GB
Page File Space 2.38 GB


https://i.postimg.cc/G2Jm3wPw/SSparts.jpg

Questions similar to mine have been asked and answered:
https://askubuntu.com/questions/789998/16-04-new-installation-gives-grub-efi-amd64-signed-failed-installation-target
https://askubuntu.com/questions/1028703/the-grub-efi-amd64-signed-package-failed-to-install-target

The general solution is to be certain the target drive is set up per UEFI specifications so that the Grub bootloader installs in the esp partition. One of the solutions is a (painful) manual method for installing Grub should the normal Ubunutu installer fail. I have not attempted the manual installation.

After the failed installation, I looked into the esp partition:

https://i.postimg.cc/ZRhqhKdx/SSgparts.jpg

The grubx64.efi binary was installed in the correct directory of the esp partition – no need to manually install it. The error message, however, announces that grub was not installed to the /target/ which in my case is /dev/sda6. That would be the partition in which I am trying to install the Ubuntu operating system. I never specified that partition during the installation process and left the bootloader installation pointer at the default /dev/sda.

Ultimately I was able to boot into Ubuntu via rEFInd, which I also have installed in the esp partition. I updated Grub, sudo update-grub, and was able to boot into Ubuntu via the normal method. Unfortunately, a few packages, such as gparted and bleachbits (there may be others) do not launch due to missing files. Apparently the error message didn't allow installation to complete in spite of Grub being the last item to install.

Is the Ubuntu installer broken, or am I missing something obvious?

[oldfred]

I know gparted is removed during install as you cannot use it on mounted partitions.
But I install it as one of the first things I install, so I can work on flash drives or my sdb drive.

/target is the ESP for UEFI installs, so it was not mounted correctly during install.
Posted work around to manually unmount & mount correct ESP during install
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229488
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1229488

[Yogi2]

Oldfred – thank you for you response, but the first three links answer the wrong question. I've not read the last link entirely, but it appears to have some very useful information that needs some in depth study.

The bug reports are dated 2014 and describe how the Ubuntu installer, ubiquity, invariably places Grub in the first esp partition it finds. The year is 2019 as I write this and the bug STILL exists. The most problematic situation occurs while trying to install Ubuntu to a removable device, generally a USB flash memory stick. The best comprehensive and easily understandables solution to that particular problem is in a Linux Mint tutorial found here: https://forums.linuxmint.com/viewtopic.php?t=287353 Some of the same solutions in the bug report are made clear and usable in the Linux Mint tutorial.

But that is not my dilemma. I am not trying to install to a USB memory stick.

I have an MSI laptop wherein three versions of Linux are installed on the same hard drive as is Windows 10 (Insider Preview); Ubuntu 19.04, Kali Linux, and Mageia 7 all installed as expected and lived peacefully with Windows for several months. With the release of Ubuntu 19.10 I deleted the partition containing Ubuntu 19.04 hoping to have an easy time replacing it. I used mkusb to create a live disk to install Ubuntu 19.10 and everything seemed to go well until the end of the installation where the following error message was issued:

The 'grub-efi-amd64-signed' package failed to install into /target/. Without the GRUB boot loader, the installed system will not boot.

Gparted showed that /dev/sda6 is the mount point /target and I am interpreting that to mean ubiquity was trying to install Grub into that partition. I did not specify that partition for Grub and assumed it would all be written to the first esp partition as ubiquity is wont to do. I verified that Grub was in fact installed to the esp partition; shown in the embedded graphic. While this may be a problem for people wanting Grub in some other location, /dev/sda2, the only esp partition on my hard drive, is perfect for my multi-boot situation. Unfortunately, because the error was generated (erroneously?) the installation was interrupted and did not complete. I think that is why some packages do not launch.

I am perfectly happy with the Ubuntu boot loader being part of the Windows boot manager – inconvenient, but acceptable for now. However, no matter how I try to install Ubuntu 19.10 that error message is generated every time.

My question is, “Am I doing something wrong, or does the Ubuntu installer have yet another known bug?”

[oldfred]

When I installed 19.10, I used the work around I posted to put its grub efi boot loader into my ESP on sdb. I have 18.04 as my main working install and its grub UEFI boot files in the ESP on sda. Before new install would always overwrite my 18.04 grub. But found I could just edit the grub.cfg in the ESP back to the UUID of my 18.04 install.

So not sure what it mounted and thought it should use.
Yes bug reports are old and they do not seem to fix them. It also is unique to Ubiquity as I have installed Fedora & Debian and they let me correctly choose where to install grub. They change a lot of grub to have "ubuntu" description in many places. Not sure if newest is still that way or not as I reviewed 2.02 and now it is 2.04 grub.

The target may be the install partition, but then the ESP must be mounted at /target/boot/efi for grub to install. I open terminal during install and see what is mounted where.

[Yogi2]

The Gparted screenshot was taken right after the error message was generated. It shows the EFI partition mounted as well as the partition targeted for the OS install. My suspicions were raised when I saw the /target designation because that is the name appearing in the error message. It suggests Ubiquity is trying to install Grub where it doesn't belong.

To be honest, Oldfred, I'm not entirely clear on the workaround. I will indeed study it more and try to comprehend all the thoughts in that thread. However, I presume that since you are offering a workaround instead of a solution the answer to my question is that Ubiquity is broken. Still. I used to like Ubuntu and thought they were on the cutting edge, but I'm having second thoughts now that I see a bug in the installer has been ignored for so many years.

I want to see what Ubuntu 19.10 has to offer and would love to test that out on my hard drive. Apparently that won't happen any time soon. I did manage to use Virtual Box to install it to a USB memory stick where it only took about an hour to get around the Nvidia driver problem inherent in the kernel. Oddly enough, no installation errors show up there.

[oldfred]

As long as your install is or can use the default drive's ESP, Ubiquity works. And that is most users.

It is just those installing to a second drive, internal (often optional) & particularly external drives (really required) that do not want grub installed to first internal drive that Ubiquity does not give a user a choice. The BIOS install version does give choice. And choice option is still there with UEFI install, but is ignored.And even trying to unmount the ESP with do not use, and trying to use another ESP does not work. Trying to unmount ESP before starting install does not work. Only unmounting during install after Uquity has set mount point of ESP works.

[Yogi2]

A fairly safe way to disable the default EFI partition is to simply remove the boot, esp flags prior to running Ubiquity - set them back after installation is complete. There is also the option of physically removing the hard drive, but setting the flags is easier. Also, installing Ubuntu to a detachable memory from within Virtual Box will leave the EFI partition on /sda unharmed, Ubiquity notwithstanding.

But that's not what I'm dealing with here. I want to install Ubuntu 19.10 on /dev/sda wherein Windows and three Linux distributions have been coexisting for a few months. I don't understand why I'm getting the error message because this is the default drive's ESP wherein Ubiquity is said to work. In fact it did install something into that ESP partition but I got the error message anyway. I think it's due to Ubiquity trying to install Grub onto /dev/sda6, which is the installation target partition, but I can't be sure.

My latest attempt was to run Ubiquity headless, minus the Grub bootloader. In my particular situation I have rEFInd installed, which takes the place of Grub and allows me to boot into Ubuntu 19.10 that way. Once in, I ran sudo update-grub and that might have modified the boot directory grub but it did not change whatever was put into the ESP partition. Thus I could not boot into Ubuntu via the Windows boot manager.

Taking a line from your previous suggestion:

Before new install would always overwrite my 18.04 grub. But found I could just edit the grub.cfg in the ESP back to the UUID of my 18.04 install. I checked the UUID specified in grub.cfg located in the ESP and it did not agree with reality. I changed it and am now able to boot Ubuntu 19.10 normally. The rout to this point was highly convoluted, and from what I can tell Ubiquity is malfunctioning. There has to be a better way.

[oldfred]

Glad you managed to get it to work.

I have tried the remove boot flag from ESP and only have boot flag on ESP on sdb. And unmounted ESP on sda, and set sdb's ESP as use as ESP. And change combo box, which only seems to work for BIOS install.
And Ubiquity still mounted the ESP on sda, that I booted from. Only by editing mount in middle of install could I get it to install to anything other than sda.

If you have details, you can post that info in one or more of the bug reports. The more that post, perhaps then someone may notice.

[Yogi2]

oldfred - Just to be clear, it appears as if you and I are addressing two different problems, i.e., bugs in Ubiquity. Your work-around applies to installations on removable devices. I am not trying to install to a removable device. I am trying to install to the internal SSD and onto a partition previously occupied by a former version of Ubuntu. Thus, unmounting the ESP partition, or otherwise disabling it, would be counter productive. I want a viable grub to end up there.

I've never posted a bug report and I'm not sure I have enough expertise to do it for this problem. I know the error message I am getting is irrational because it states Grub failed to install to the /target/. Ubuquity should not have attempted to install Grub there in the first place. Because of the timing of the error, the installation does not complete. The installer shuts down instead of continuing without Grub. Also, Grub and everything else required for booting was written to the SSD's ESP partition. Booting into the partially installed Ubuntu failed because the UUID in EFI/grub.conf was incorrect. I changed it to the correct UUID after I re-ran Ubiquity sans Grub, or sudo ubiquity -b. Additionally, I updated Grub from within the now working Ubuntu 19.10 and can see all the other OS's as selections from the Grub menu.

I don't want to sound sarcastic, but given the history of Ubiquity the only solution I see is to move on to some other distro that is not infested with bugs in its installer.