SecureBoot-enabled bootloader can be overwritten with non-SB without warning

[gratefulfrog]

I was previously running XUbuntu 15.04 on my Asus UX303L laptop.

The configuration is dual boot with windows 8.1.

I ran the upgrade via the software updater and it proceeded normally.

Upon reboot, I got a red screen saying that something was wrong with secure boot and it had to be fixed in the BIOS.

In BIOS, I disabled Secure boot and was again able to access XUbuntu.

I would like to re-enable secure boot, but cannot.

I am happy to help debugging in any way - I am a qualified computer scientist.

Sincere thanks,
Bob

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: linux-image-4.2.0-18-generic 4.2.0-18.22
ProcVersionSignature: Ubuntu 4.2.0-18.22-generic 4.2.3
Uname: Linux 4.2.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: bob 1533 F.... pulseaudio
 /dev/snd/controlC1: bob 1533 F.... pulseaudio
CurrentDesktop: XFCE
Date: Thu Nov 19 19:25:08 2015
HibernationDevice: RESUME=UUID=e7d92749-23e5-464f-93dc-6e0826746396
InstallationDate: Installed on 2015-05-11 (192 days ago)
InstallationMedia: Xubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422.1)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 8087:0a2a Intel Corp.
 Bus 001 Device 002: ID 064e:9700 Suyin Corp. Asus Integrated Webcam
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: ASUSTeK COMPUTER INC. UX303LNB
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-18-generic.efi.signed root=UUID=eba1a0f5-161a-4061-99a4-b5598f7692c1 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.2.0-18-generic N/A
 linux-backports-modules-4.2.0-18-generic N/A
 linux-firmware 1.149.2
SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: Upgraded to wily on 2015-11-19 (0 days ago)
dmi.bios.date: 01/22/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX303LNB.206
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX303LNB
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX303LNB.206:bd01/22/2015:svnASUSTeKCOMPUTERINC.:pnUX303LNB:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX303LNB:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: UX303LNB
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.
---
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
BootEFIContents:
 grub.cfg
 grubx64.efi
 MokManager.efi
 shimx64.efi
CurrentDesktop: XFCE
Dependencies:

DistroRelease: Ubuntu 15.10
EFIBootMgr:
 BootCurrent: 0001
 Timeout: 1 seconds
 BootOrder: 0001,0000
 Boot0000* Windows Boot Manager HD(1,GPT,0212eb73-6de7-4e9f-afcf-adb7829c9a83,0x800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
 Boot0001* ubuntu HD(1,GPT,0212eb73-6de7-4e9f-afcf-adb7829c9a83,0x800,0x32000)/File(\EFI\UBUNTU\GRUBX64.EFI)
InstallationDate: Installed on 2015-05-11 (192 days ago)
InstallationMedia: Xubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422.1)
NonfreeKernelModules: nvidia
Package: shim 0.8-0ubuntu2
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 4.2.0-18.22-generic 4.2.3
Tags: wily
Uname: Linux 4.2.0-18-generic x86_64
UpgradeStatus: Upgraded to wily on 2015-11-19 (0 days ago)
UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

[Brad Figg (brad-figg)]

This change was made by a bot.

[Steve Langasek (vorlon)]

Please run 'apport-collect 1518018' from the affected system.

The most likely explanation of this behavior is that the -signed packages (grub-efi-amd64-signed, shim-signed) have accidentally become uninstalled from your system, possibly due to a wrong apt sources configuration that pulled inconsistent packages from -proposed; this would leave you with only the unsigned packages installed, which the upgrade would then try to write as your bootloader despite being incompatible with SecureBoot.

It may be a good idea for us to check the presence of signed bootloaders + secureboot on upgrade and warn/fail if we are trying to install an unsigned bootloader; yours would not be the first report of boot problems resulting from uninstalling the secureboot bootloader package.

[gratefulfrog (gratefulfrog)]

apport information

[gratefulfrog (gratefulfrog)]

apport information

[gratefulfrog (gratefulfrog)]

Hello,

Thank you for the very quick reaction.

I ran apport-collect and I belive the info was uploaded.

I noted this:

diff: /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed: No such file or directory

Is there a way of fixing this manually? I would really like to re-enable secure boot, if at all possible.

Cheers,
Bob

[gratefulfrog (gratefulfrog)]

I loaded the signed version of grub via symantic and secure boot works again.

I noticed that grub signed conflicts with 'mkusb' which was removed. I believe that mkusb installed the unsigned version of grub and that is why secure boot failed. So it is not directly a 15.10 issue...

Maybe this bug report can be transfered to mkusb ?

Cheers,
Bob

[Steve Langasek (vorlon)]

On Fri, Nov 20, 2015 at 08:55:58AM -0000, gratefulfrog wrote:
> I loaded the signed version of grub via symantic and secure boot works
> again.

> I noticed that grub signed conflicts with 'mkusb' which was removed. I
> believe that mkusb installed the unsigned version of grub and that is
> why secure boot failed. So it is not directly a 15.10 issue...

> Maybe this bug report can be transfered to mkusb ?

There is no package named 'mkusb' in Ubuntu.

[Steve Langasek (vorlon)]

As mentioned in my preceding comment, while there will always be cases where the SecureBoot package may be removed and result in losing SB compatibility, when we know that the system has SB enabled we don't really want this to happen without warning to the user. Retitling this bug, which can be used to track this issue.