grub or kernel update broke Secure Boot by putting grubx64.efi instead of shimx64.efi in EFI boot order

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

This appears to have been caused by the publication of a grub2 security update on 12/15 without the corresponding grub2-signed package being published at the same time.

We have had similar issues in the past with publication of grub2 and grub2-signed to the -updates pockets; the proposed solution there won't help for the security pocket, however, since those publications don't go via -proposed.

Subscribing the security team for comment.

To fix your current problem, you should install the grub-efi-amd64-signed package.

Will users that have only the -security pocket enabled run into this issue until we publish a corresponding grub2-signed package into the -security pocket? Can the packages in -updates in wily, vivid, and trusty be binarycopied into the -security pocket?

What steps need to be taken to publish future grub2 security updates?

Thanks

On Thu, Jan 07, 2016 at 03:59:30AM -0000, Seth Arnold wrote:
> Will users that have only the -security pocket enabled run into this
> issue until we publish a corresponding grub2-signed package into the
> -security pocket?

Yes.

> Can the packages in -updates in wily, vivid, and trusty be binarycopied
> into the -security pocket?

That doesn't help. The grub2 and grub2-signed packages must be in exact
version lockstep to avoid problems.

> What steps need to be taken to publish future grub2 security updates?

Upon unembargo, the grub2 package needs to be copied first from the security
ppa to -proposed, where the grub .efi binaries can be signed, and then
grub2-signed needs to be uploaded to -proposed, after which the packages can
be copied to -security.

Wouldn't the grub2 package simply be held back if the proper version required by grub2-signed isn't available?

Why did the grub2-signed binary package get uninstalled during the update?

2015-12-15 20:26:59 status installed grub-efi-amd64-signed:amd64 1.55+2.02~beta2-29
2015-12-15 20:27:00 remove grub-efi-amd64-signed:amd64 1.55+2.02~beta2-29 <none>

On Thu, Jan 07, 2016 at 07:14:48PM -0000, Marc Deslauriers wrote:
> Wouldn't the grub2 package simply be held back if the proper version
> required by grub2-signed isn't available?

Not in all cases.

> Why did the grub2-signed binary package get uninstalled during the
> update?

This is allowable when running 'apt-get dist-upgrade', which is presumably
how the affected users have been applying updates.

When using update-manager, we have more control to avoid accidental removal
of packages when applying updates. When a user explicitly invokes apt-get,
we don't have control over this.

Try https://sourceforge.net/u/yannubuntu/

Dual Boot repair disk

https://sourceforge.net/projects/boot-repair-cd/files/

On Thu, Dec 27, 2018 at 08:25:41PM -0000, bokateeka wrote:
> Try https://sourceforge.net/u/yannubuntu/

> Dual Boot repair disk

Please do nothing of the sort. This "repair disk" is developed with zero
coordination with the Ubuntu developers and the resulting changes to the
disk are unsupportable by us.

This seems to have been an update publication issue in a version of Ubuntu that is no longer supported (14.10), I don't think there is bug described here that still exists.

I am setting this to "Incomplete" to give some time for anyone to confirm being affected by this, I am also downgrading severity from "Critical".