Bug Report - Grub install failed

So after a lot of distro test drives I settled on Ubuntu Budgie 19.10 until the next LTS release. You guys have really done a great job with this, really helping Ubuntu be a lot tastier in this flavor, and Budgie itself is really a lot nicer here than on Solus.

However, I have ran into an installation issue on the first machine that I cannot resolve. “Unable to install grub in /dev/sda”. This is an install that was intended as a dual boot with windows 10. I have tried numerous fixes and all of the fixes end in a road block and no solution.

Everything went fine with the install until the end, and then I got the message where grub failed to install. This seems to have happened to others as well. But it seems the fixes worked for them but not for me.

I am a very rusty heap right now when it comes to Linux. I haven’t messed with it in a long time. But I am not clueless either and this has me whipped. I can see that the partitions are there. I can see that the linux install is there. I can see that the EFI stuff is ok too. I can even use the laptop’s own boot menu and the OS is in the list. But of course when I try to just boot it that way I get the “gnu grub version 2.04 minimal bash-like editing is supported in grub” screen. I have tried to work through that path as well to no avail.

Really I’d be OK with being able to boot as expected, or by the laptop boot menu, or heck even if I could install and configure grub on a usb stick I could use to boot Ubuntu Budgie. Any ideas on how to get this working via any of these 3 methods???

At this point the only saving grace is that windows 10 still boots fine. Big butt saver since it is my daugther’s laptop for college and she just left to drive back with it. I just told her I’d try to figure it out and finish it up when she is home next.

The laptop is a Lenovo Ideapad with 1tb drive and 8gb of ram. The install media is booting EFI and that is confirmed. The installation method was via live usb, which I used the try option and then used the desktop icon to do the installation.

Installing grub manually doesn’t work. Using the boot repair tool doesn’t work, it just errors out at the end saying it boot repair requires a live session, but obviously I am in a live session. And the bash like editing doesn’t seem to work either. I am not that familiar with the newer grub2. But I think it doesn’t work because the grub stuff is not there to edit. I don’t know I have forgot a lot because I ended up pulling an all-nighter trying different fixes.

Next up is my HP laptop which is likely to go down the exact same path with the install. I’m not really ready to roll those dice though until I make some sense of what is going on with the first attempt on the Lenovo laptop.

Here is the shortened basics of fstab typed from a picture I took by the way

# / was on /dev/sda7 during installation / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation /boot/efi vfat umask=0077 0 1
# /home was on /dev/sda8 during installation /home ext4 defaults 0 2
# /storage was on /dev/sda9 during installation /storage ext4 defaults 0 2
# swap was on /dev/sda6 during installation none swap sw 0 0

What would normally happen is that the installer (ubiquity) would crash - and then ask to send the bug report to launchpad. Please do this - it will upload the relevant logs to help diagnose the issue.

It maybe a corrupt EFI boot sector - some manufacturers do this deliberately to only boot one OS (windows)

It could be that the USB stick when booting is recognised as /dev/sda - hence it is actually installing to the /dev/sdb hard-drive … but at the end the GRUB install is installing into the wrong location

I thought it did send a bug report? Maybe it didn’t?

Would I just wipe everything out and start over, or is the installer smart enough to jump to check and move on to the grub install since everything else is already installed?

I didn’t see anything indicative of it trying to install to the wrong letter. The hard drive was sda and everything else did ok?

What would I be looking for in the efi boot sector? I Can have a look at that as well.

I may get a chance to work on correcting this issue this weekend. I was hoping to have a little more insight by then though.

Laptop is here to try to deal with this now.

Anyone have any answers or suggestions?

Well, I opted to boot windows, blow it all out, then reboot into the live usb and start all over.

This time I opted to select to install grub to /dev/sda1 Windows Boot Manager

The install of Grub2 failed again. Only difference this time is that the message was a little different.

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

The only option was to click OK which I did. Next the only option was to continue the live session or reboot. No bug report launch pad came up.

Can anyone tell me what I am looking for in the EFI partition that might cause any problems?

It does not make any sense to me. I mounted the EFI partition. The first layer directories are BOOT - EFI - System Volume Information - boot-repair

Inside EFI is Boot - Insyde - Microsoft - ubuntu

Inside ubuntu is BOOTX64.CSV - grub.cfg - grubx64.efi - mmx64.efi shimx64.efi

grub.cfg doesn’t have much in it but lists root hd0, gpt7 (which is what / was for install)

I tried a manual install of grub via Tilix.
fdisk -l shows me /dev/sda1 is EFI System
I mounted /dev/sda7 as well as --bind for /dev /proc and /sys
I chroot to sda7
ran grub-install /dev/sda1

It comes back error: cannont find EFI directory

same is true if I try /dev/sda

Again if I cd over to the partition mount point in Tilix and run ls -a well there is the EFI listed?
So it is there.

I’m tired now. Is it a permissions issue? drwxr-xr-x

I have never had an issue installing any distro. But this one is proving problematic, which I am guessing is due to trying to dual boot with windows 10 and this EFI stuff. But it shouldn’t be this annoying at this point. It’s been out for years.

I don’t think I can articulate how frustrating it is to have installed twice and have the OS sitting right there on the drive and not be able to boot it.

I figured out a workaround myself, purely from banging around in Tilix long enough to execute in frustration. Here is the workaround for anyone else that experiences this.

Open up Tilix and run the following…
(substitute the drive and partition you installed your / directory on mine was sda7)
(drive sda partition 7)

ubuntu-budgie@ubuntu-budgie:~$ sudo mount /dev/sda7 /mnt

ubuntu-budgie@ubuntu-budgie:~$ sudo mount /dev/sda1 /mnt/boot/efi

ubuntu-budgie@ubuntu-budgie:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done

ubuntu-budgie@ubuntu-budgie:~$ sudo chroot /mnt

(again substitute the drive letter you need grub on, mine was sda)

root@ubuntu-budgie:/# grub-install /dev/sda
Installing for x86_64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: vars_set_variable: write() failed: Interrupted system call.
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-budgie:/# sudo update-grub

I executed the last command in frustration even though it said it didn’t install, because I knew there was no grub.cfg I was fried out of options and hoped any error message might offer a clue.

I lucked out and that ran and updated grub sorta. Created the grub.cfg file I needed anyways. I rebooted, hit the key I needed to in order to access the laptop’s UEFI boot selection screen. I selected Ubuntu and it booted right up.

Newcomers with also need to know that you will then want to reboot again, hit the key to go into the bios, and adjust the UEFI boot order to put Ubuntu on top so that you don’t have to hit the UEFI boot key every time you want to boot Ubuntu. This will make it boot the Ubuntu option every time which will give you the Grub2 menu where you can select Ubuntu or any other OS you have on the machine to boot.

However, I do not consider this fixed nor solved. It’s just worked around.

Whatever issue that was interfering with the grub installation still exists and I have seen proof of that when I ran the Software Updater and there were a few errors with grub level stuff there.

I am still confused on what the root cause is on the Lenovo. I wish I could figure that out. There are a lot smarter people than me and I hope one of them takes time to look at all this, figure out the root cause and a real fix.

Thanks for the update!

That smacks of Lenovo screwing up the EFI boot sector - as I mentioned previously some manufacturers have screwed up their EFI implementations. Nothing that linux folk can do about that.

But you are right there are much smarter people who may have discovered solutions - possibly recreating the EFI boot sector. Problem comes if the Lenovo screwed implementation is in their firmware though.

This applies particularly to new Lenovo notebooks:
You should never boot in CSM/Legacy/BIOS mode if Windows is UEFI boot.
Overcome this by creating a new GPT/UEFI boot using Rufus under Windows.
For some reason UEFI is so slow, but in the end it worked, creating grub ubuntu/windows nice!

Humm, I will look in the bios again when I can get my hands on it again.

I bought it with windows 10 off the shelf and as far as I know it was UEFI. I know it was a boot screen option (windows boot loader) and it a EFI partion, and windows boot entries within when I mounted it, etc.

And I installed ubuntu budgie in UEFI mode, etc.

This however certainly does not mean that the bios setting for mode is correct. It could be set in a mixed mode or something I did not notice because I saw UEFI. And I would not doubt that. The bios has been updated a few times and also we have had a couple problems with this laptop having issues after a windows update, which required me to remove the battery and the cmos battery to get basic things back working like the keyboard.

Thanks for the lead on something to look for because the workaround I did is just a workaround, not a fix of the root cause.

Think I need to add this reference:
Grub prompt only

Yes that is good to link to this for similar issues.

Here is an example of why I say my methods to get booting are just a workaround, not a fix.
Maybe it will provide some clues to the root problem?

sudo apt-get install libcanberra-gtk3-module
[sudo] password for user:
Reading package lists… Done
Building dependency tree
Reading state information… Done
libcanberra-gtk3-module is already the newest version (0.30-7ubuntu1).
libcanberra-gtk3-module set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 21 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up grub-efi-amd64-signed (1.128.1+2.04-1ubuntu12.1) …
Installing for x86_64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: efivarfs_set_variable: writing to fd 7 failed: Interrupted system call.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Interrupted system call.
grub-install: error: failed to register the EFI boot entry: Interrupted system call.
dpkg: error processing package grub-efi-amd64-signed (–configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of shim-signed:
shim-signed depends on grub-efi-amd64-signed | grub-efi-arm64-signed; however:
Package grub-efi-amd64-signed is not configured yet.
Package grub-efi-arm64-signed is not installed.

dpkg: error processing package shim-signed (–configure):
dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Question - does the same issue occur if you turn off secure boot in the efi settings?