grub-efi-amd64-signed Forced Uninstall Causes Boot Failure

[Vindicator]

Yesterday, I tried to run an apt-get install when it said it could continue because of some "partial" something or other and I noticed it wanted to remove "grub-efi-amd64-signed".
I went ahead and let it update on it's own as it desired.

Then a little while ago I had to reboot for an unrelated reason, but I find myself no longer able to boot. Not just not able to boot, but there is no GRUB or EFI shell.

Boot-Repair from Live CD wouldn't complete due to "purge cancelled" for "grub-efi-amd64-signed".
While in Live-CD, I'd chroot to my system and run "grub-install" and "update-grub", and while they both succeeded, nothing had changed on boot.

I ended up disabling Secure Boot for now, but wanted to let you know something went horribly wrong.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: grub-efi-amd64-signed (not installed)
Uname: Linux 4.0.0-040000-generic x86_64
ApportVersion: 2.17.2-0ubuntu1.1
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Jun 30 02:58:32 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-06-18 (11 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
SourcePackage: grub2-signed
UpgradeStatus: No upgrade log present (probably fresh install)

[Vindicator (vindicator)]

I should also add that it looks to be forced to be removed because "grub-efi-amd64" was updated to:
2.02~beta2-22ubuntu1.1
vs
2.02~beta2-22ubuntu1 which is what grub-efi-amd64-signed (1.46+2.02~beta2-22ubuntu1) depends on.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Fabricio Biazzotto (fbiazzotto)]

Also it seems to be impossible to force the old 2.02~beta2-22ubuntu1 version, at least on Synaptic.

[Fabricio Biazzotto (fbiazzotto)]

I had to run from shell:
sudo apt-get --reinstall install grub-efi-amd64=2.02~beta2-22ubuntu1 grub-efi-amd64-bin=2.02~beta2-22ubuntu1 grub-common=2.02~beta2-22ubuntu1 grub2-common=2.02~beta2-22ubuntu1 grub-efi-amd64-signed
sudo apt-mark hold grub-efi-amd64 grub-efi-amd64-bin grub-common grub2-common

It's just a temporary fix, grub-efi-amd64-signed package must be updated ASAP.

[John doe (r9-launchpad-fq)]

Outch! Thanks for the report, I just stop before dist-upgrading. Hope the bogus dependence will be fixed soon to avoid lots's of end-users support!

[DaytonaJohn (daytonajra)]

Just a bit more information. The secure boot fails because these updates replace the signed grubx64.efi with an unsigned version. I copied a signed grubx64.efi from a backup (overwriting the one from the updates), and now my secure boot is working correctly again.

[Robie Basak (racb)]

You should be able to fix this by either:

1) Not agreeing to remove grub-efi-amd64-signed but instead waiting for an update for it (and filing a bug pointing out that it is unavailable as appropriate) - but of course I appreciate that users don't magically know this and shouldn't have to.

2) Later installing grub-efi-amd64-signed again.

If the second fix doesn't work, please report the output of "apt-cache policy grub-efi-amd64 grub-efi-amd64-signed".

There was a short window of a few hours just after the grub2 update was released on 8 July when the signed package was not released concurrently and apt-get would have (wrongly) recommended removal of the signed package as a consequence. This was due to a process issue. Since then though, the problem should not recur as the grub-efi-amd64-signed was released after a few hours. However manual recovery is required (unfortunately) for those affected by using the second step above.

So I'm marking this Fix Released as it should be now fixed, but if it is not please explain and reopen.

[DaytonaJohn (daytonajra)]

Copied it to /boot/efi/EFI/ubuntu/grubx64.efi

On 12/10/2015 07:27 PM, Bill Miller wrote:
> DaytonaJohn (daytonajra), where did you copy the signed grubx64.efi to?
> Was it to /usr/lib/grub? Thanks for any help.
>

[Bill Miller (wbmilleriii)]

Thank you very much

[shemgp (shemgp)]

On Xenial dev version now and this bug is showing up again.