grub-efi-amd64: prompted to disable SecureBoot on upgrade from 2.02~beta2-36ubuntu2 to 2.02~beta2-36ubuntu3

[Steve Langasek]

Despite the fact that grub2 2.02~beta2-36ubuntu3 was a no-change rebuild, upon upgrading to it on my system, I received a debconf prompt offering to disable UEFI secure boot.

This system has Secure Boot enabled and has no dkms modules installed. There should not be a prompt by grub on upgrade to disable; if this was going to be shown at all (which it wasn't, and shouldn't have been), it should have happened on the initial xenial upgrade.

Looking at the postinst code, I see that it prompts if the dkms package is installed:

    # nothing to do if there is no dkms package installed.
    if ! dpkg -l dkms | grep -qc ii; then
        return
    fi

Ok, I do have the dkms package installed, even though I don't have any dkms-using packages installed. (BTW, 'grep -qc ii' should probably be written 'grep -q ^ii') But then, this prompt should have shown up for me during the upgrade to xenial, *not* in this minor upgrade to the grub package. So why did it not?

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: grub-efi-amd64 2.02~beta2-36ubuntu3
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Sun Apr 17 11:27:09 2016
InstallationDate: Installed on 2010-09-24 (2032 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
SourcePackage: grub2
UpgradeStatus: Upgraded to xenial on 2016-04-15 (2 days ago)

[Steve Langasek (vorlon)]

Critical, because if there's a bug causing the prompt to be missed on upgrade to xenial, users are going to find their module support degraded without warning.

[Launchpad Janitor (janitor)]

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

[Mathieu Trudel-Lapierre (cyphermox)]

There is still some work needed here; update-secureboot-policy may prompt in the wrong cases. Moving to 'ubuntu-17.05', since it's not the principal focus while scrambling to release Zesty.

Most of the required work here is going to be to properly handle /proc/sys/kernel/moksbstate_disabled and /proc/sys/kernel/secure_boot in update-secureboot-policy; and all of it will be done in the shim-signed package.

[Steve Langasek (vorlon)]

Xenial is now in extended support, and only one other user reported being affected by this bug. So by and large this seems to have not been a significant issue; and post-xenial, it's even less of a problem because it should only affect upgrades *to* xenial. Therefore marking this wontfix, barring any further information.