OK, don't know where pavlos will suggest going for you , but in Mac, when we boot the machine into the OSX boot manager window, it shows the options for disks to boot . . . to get an EFI install done properly you should select the "EFI Boot" disk image, and then your install should . . . be "EFI" friendly????
I don't know if that is relevant to your PC or if trying his suggestion of not going EFI would be best???
Pavlos, Control-c is not stopping the process
The ubuntu live usb stick has both options to do an efi or non-efi install. Since the laptop boots in efi mode, it will choose the first. LUX, I assume if you look at gparted, your disk sda shows sda1 /boot/efi and sda2 / Still, within the chroot env
ls /usr/lib/grub/
do you have 2 dirs (x86_64-efi and x86_64-efi-signed) and a link (grub-mkconfig_lib)?
grub-install --efi-directory=/boot/efi
grub-install --target=x86_64-efi /dev/sda
any success?
Pavlos, I cannot give instructions, system is still in a loop, looks like I have to answer yes to terminate it. I will run gparted from menu and see
ok, say yes to that screen, it should be back to the # prompt.
Run gparted and see that we have our 2 partitions. Try
grub-install --target=x86_64-efi /dev/sda
grub-install --recheck /dev/sda
It should say, Installation finished, no errors.
after I say yes the prompt were:
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0003.
grub-install: warning: vars_set_variable: write() failed: Invalid argument.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: No such file or directory.
grub-install: error: failed to register the EFI boot entry: No such file or directory.
W: Operation was interrupted before it could finish
root@ubuntu-mate:/# ^C
root@ubuntu-mate:/#
GPARTED running form menu has not changed at all.
The first instruction rub-install --target=x86_64-efi /dev/sda failed
root@ubuntu-mate:/# grub-install --target=x86_64-efi /dev/sda
Installing for x86_64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0003.
grub-install: warning: vars_set_variable: write() failed: Invalid argument.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: No such file or directory.
grub-install: error: failed to register the EFI boot entry: No such file or directory.
root@ubuntu-mate:/# ^C
root@ubuntu-mate:/#
ls /sys/firmware/efi/efivars/dump-*
Do you have variables in there? remove them
# rm /sys/firmware/efi/efivars/dump-*
And then run the usual
update-grub
grub-install -v --target=x86_64-efi --recheck /dev/sda
OK, well, in OSX when trying to run a linux install it doesn't auto-select "EFI boot" option, we have to manually select that or it defaults to non-EFI option. Just asking because it doesn't seem to be accepting the install, so question is "why"??? Anyway, check back tomorrow on this topic . . . I'm out, G . . . .
The system is not recognizing the first instruction
root@ubuntu-mate:/# ls /sys/firmware/efi/efivars/dump-*
ls: cannot access '/sys/firmware/efi/efivars/dump-*': No such file or directory
root@ubuntu-mate:/# ^C
root@ubuntu-mate:/#
there should be a bunch of files in /sys/firmware/efi/efivars/, maybe none start with dump-
there is no boot0003 variable --that's the one trying to write.
update-grub
grub-install -v --target=x86_64-efi --recheck /dev/sda
do these run?
Pavlos, I don't know the country where you are living, maybe it is late in the night.
Please let me know and we leave it for tomorrow.
I will leave de laptop on and running from the USB stick.
I am in Santiago Chile and it is 21:22 hr.
I do not want to abuse with your pacience and good willness
I'm in Phoenix, it is 6:23pm but I understand you're tired as heck.
We'll continue tomorrow, maybe others can join who have more experience.
Ok... let see, anyway I will be close to the computer during the next 30 minutes, just if an idea cames to your mind and to intend it.
Thanks a lot
Hi LUXKAK,
is your device 32 Bit only?, if it is, you won't be able to install UM 20.04 on it as UM 20.04 is 64 Bit only!. 
He was booted in the live iso of 20.04, could he do that if his computer is 32 bit? He could boot the iso and it would work, but then the install grub would fail?? This seems to be one of those . . . try a fresh install moments, no? Go back to installing 18.04, if that worked before, and then try to upgrade via GUI "Software & Updates" or via console with "sudo do-release-upgrade" . . . ??
The catch seems to be getting grub operational, and that's where SuperGrub2 comes in very handy; to find out if you can boot the installed "/" or not even that. But, whatever comes next it seems like you could add your name to a bug report somewhere on this "failure to install grub" in a friendly manner????
