14

After running sudo do-release-upgrade this morning to upgrade my system from Ubtunu 17.10 to 18.04 LTS, I encountered errors during the upgrade. The trace is too long to post in it's entirety, but here is the part that (to me) looks like the problem:

Rebuilding /usr/share/applications/bamf-2.index...
Errors were encountered while processing:
 shim-signed
 grub-efi-amd64-signed
Exception during pm.DoInstall():  E:Sub-process /usr/bin/dpkg returned an error code (1)

Could not install the upgrades 

The upgrade has aborted. Your system could be in an unusable state. A 
recovery will run now (dpkg --configure -a). 

Setting up shim-signed (1.34.9+13-0ubuntu2) ...
Installing for x86_64-efi platform.
Could not add entry to BootOrder: Interrupted system call
grub-install: error: efibootmgr failed to register the boot entry: No such device or address.
dpkg: error processing package shim-signed (--configure):
 installed shim-signed package post-installation script subprocess returned error exit status 1
Setting up grub-efi-amd64-signed (1.93+2.02-2ubuntu8) ...
Installing for x86_64-efi platform.
Could not add entry to BootOrder: Interrupted system call
grub-install: error: efibootmgr failed to register the boot entry: No such device or address.
dpkg: error processing package grub-efi-amd64-signed (--configure):
 installed grub-efi-amd64-signed package post-installation script     subprocess returned error exit status 1
Errors were encountered while processing:
 shim-signed
 grub-efi-amd64-signed

Upgrade complete

The upgrade has completed but there were errors during the upgrade process.

I've browsed the forums for solutions and can preemptively confirm that the entries in /etc/fstab are not commented out. cat /etc/fstab outputs the following:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda9 during installation
UUID=a2f91309-dc7e-4456-b3ef-89900b145365 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda2 during installation
UUID=90EA-4FB8  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sda6 during installation
UUID=2f80d8f4-5609-45e1-854d-578ab25836c3 none            swap    sw              0       0

The system is a dual-booted with Windows 10. Through lsb_release -a I can confirm that my Ubuntu partition did update to 18.04 LTS, but these errors unnerve me and I don't want them causing problems in the long term. Thank you.

R. Barrett
  • 143

1 Answers1

19

I had the exact same error. The solution I found in order to upgrade the remaining last 2 packages was:

sudo su -
cd /boot/efi/EFI
mv ubuntu ubuntu-old
apt install -f
mv ubuntu-old ubuntu
update-grub2
exit

I hope it helps.

George Tavantzopoulos
  • 494
  • 3
  • 8
  • Interesting solution. Could you explain why the mv ubuntu ubuntu-old and restoration after apt install -f? – WinEunuuchs2Unix May 05 '18 at 22:57
  • 1
    @WinEunuuchs2Unix It seems that the newer grub couldn't access the /boot/efi/EFI/ubuntu directory, for some reason. So since my system was booting normally, I want just to get rid off that error everytime I was using the apt. So I thought that workaround just to check it the installation would finish and it seems that worked. Lastly, I restored the ubuntu directory name just not mess around with my system's ability to boot. It seems, I forgot to mention to issue an update-grub2 afterwards. – George Tavantzopoulos May 07 '18 at 08:04
  • Seems to have worked a treat. Thank you very much! – R. Barrett May 28 '18 at 06:48
  • 1
    It worked for me so posted the workaround to the launchpad bug: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518 – Rqomey Aug 08 '18 at 10:00
  • It worked for me on Ubuntu 18.04 with Uuntu installed on secondary SSD drive (Linux stephane-N56VM 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux) – Stéphane V May 27 '19 at 10:43