upgrade crashing due to unsigned kernels

Bug #1788727 reported by Al Weeks
276
This bug affects 69 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Fix Released
High
Unassigned
Bionic
Fix Released
High
Unassigned
Cosmic
Fix Released
High
Unassigned
grub2-signed (Ubuntu)
Fix Released
Undecided
Unassigned
Bionic
Fix Released
Undecided
Unassigned
Cosmic
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
All upgrades on UEFI from xenial to bionic.

[Test case]
1) Install Ubuntu 16.04, on an UEFI system with Secure Boot enabled.
2) Upgrade to 18.04; validate that the upgrade is successful and does not fail due to "unsigned kernels" as an error message / debconf prompt.

[Regression Potential]
Things to watch out for are continuing with an upgrade from 16.04 to 18.04 where only unsigned kernels are available, despite the running kernel at upgrade-time being included with a .efi.signed file -- if neither the .efi.signed file is signed nor the vmlinuz for that particular kernel version, the upgrade should fail to avoid letting users upgrade into a non-working system.

---

$ ls /boot/vmlinuz-*
/boot/vmlinuz-4.4.0-130-generic
/boot/vmlinuz-4.4.0-130-generic.efi.signed
/boot/vmlinuz-4.4.0-133-generic
/boot/vmlinuz-4.4.0-133-generic.efi.signed
/boot/vmlinuz-4.4.0-134-generic
/boot/vmlinuz-4.4.0-134-generic.efi.signed
/boot/vmlinuz-4.4.0-135-generic
/boot/vmlinuz-4.4.0-135-generic.efi.signed
$

On dist-upgrade from xenial to bionic, grub bails with the error:

 │ Cannot upgrade Secure Boot enforcement policy due to unsigned kernels │
 │ │
 │ Your system has UEFI Secure Boot enabled in firmware, and the following │
 │ kernels present on your system are unsigned: │
 │ │
 │ 4.4.0-135-generic │
 │ 4.4.0-134-generic │
 │ 4.4.0-133-generic │
 │ │
 │ │
 │ These kernels cannot be verified under Secure Boot. To ensure your │
 │ system remains bootable, GRUB will not be upgraded on your disk until │
 │ these kernels are removed or replaced with signed kernels. │

This is a false positive, only the -generic files are unsigned, not the .efi.signed ones; and only the .efi.signed ones are referenced in the grub.cfg. So the fact that there are unsigned vmlinuz files in the directory alongside the signed ones should not block grub from upgrading.

---

ProblemType: Package
DistroRelease: Ubuntu 18.04
Package: grub-efi-amd64 2.02-2ubuntu8.3
Uname: Linux 4.7.0-040700-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Thu Aug 23 19:33:07 2018
ErrorMessage: installed grub-efi-amd64 package post-installation script subprocess returned error exit status 1
InstallationDate: Installed on 2018-05-30 (85 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.7.0-040700-generic root=UUID=d9d727a6-5798-4fe1-8ac0-fb79b1d05431 ro quiet splash vt.handoff=7
Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3ubuntu1
PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1
RelatedPackageVersions:
 dpkg 1.19.0.5ubuntu2
 apt 1.6.3ubuntu0.1
SourcePackage: grub2
Title: package grub-efi-amd64 2.02-2ubuntu8.3 failed to install/upgrade: installed grub-efi-amd64 package post-installation script subprocess returned error exit status 1
UpgradeStatus: Upgraded to bionic on 2018-08-23 (0 days ago)

Revision history for this message
Al Weeks (lightkeeper13) wrote :
tags: removed: need-duplicate-check
Phillip Susi (psusi)
summary: - package grub-efi-amd64 2.02-2ubuntu8.3 failed to install/upgrade:
- installed grub-efi-amd64 package post-installation script subprocess
- returned error exit status 1
+ upgrade crashing due to unsigned kernels
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Julian Andres Klode (juliank) wrote :

That's by design to prevent you from installing a bootloader on a system where you have no kernel that will boot.

Changed in grub2 (Ubuntu):
status: Confirmed → New
status: New → Opinion
Revision history for this message
Bruno Cornec (bruno-cornec) wrote :

I had the same issue whn upgrading from 17.10 to 18.04 and used the following workaround:

cd /boot
mkdir unsigned
mv vmlinuz-4.10.0-40-generic vmlinuz-4.10.0-42-generic vmlinuz-4.13.0-46-generic unsigned/
apt-get upgrade

and voila problem solved :-)

It seems that unsigned kernels are left in the /boot directory (not used it seems) which prevents the grub update mechanism to happen correctly. So I think the "design" is wrong and that unsigned kernel in SB mode should just be ignored and shouldn't prevent the postinstall to proceed.

Just my 0.02€ and YMMV of course

Revision history for this message
alex cuellar (puca-sunqu) wrote :

My kernel is Linux 4.16.14-041614-generic, It's possible that's why

Revision history for this message
William W. Hager (whager) wrote : Re: [Bug 1788727] Re: upgrade crashing due to unsigned kernels

Julian,

I gave up on the upgrade and installed a fresh version of 18.04, which
worked
fine. I guess the bug is in the upgrade process.

Bill

On 09/03/2018 03:07 AM, Julian Andres Klode wrote:
> That's by design to prevent you from installing a bootloader on a system
> where you have no kernel that will boot.
>
> ** Changed in: grub2 (Ubuntu)
> Status: Confirmed => New
>
> ** Changed in: grub2 (Ubuntu)
> Status: New => Opinion
>

--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ _/
_/ / / / ____/ William W. Hager _/
_/ / / / / 462 Little Hall _/
_/ / / / ____/ Department of Mathematics _/
_/ /__/ / / UNIVERSITY OF FLORIDA _/
_/ _______/ __/ Gainesville FL 32611-8105 _/
_/ _/
_/ Phone : (352) 294-2308 E-mail : <email address hidden> _/
_/ FAX : (352) 392-8357 https://people.clas.ufl.edu/hager/ _/
_/ _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Revision history for this message
Braden McGrath (zprime) wrote :

While it may be "by design," then the package system or something else is broken "by design."

On a system that uses signed kernels, the unsigned versions of the same kernels are also installed alongside. When I upgraded from 16.04 to 18.04, Grub choked because it found the unsigned kernels (which I wasn't even using).

Possibly the process behind installing signed kernels should be investigated? Currently, when you install the signed version via apt, this has a dependency on the unsigned version, both are installed simultaneously, and that doesn't seem like it should be the case.

Revision history for this message
Phillip Susi (psusi) wrote :

Having *any* unsigned kernel should not fail the upgrade process. At best, a debconf warning should be presented.

Changed in grub2 (Ubuntu):
status: Opinion → New
status: New → Confirmed
Revision history for this message
Sandi Vujaković (elsandosgrande) wrote :

The workaround that I have is removing all UKUU added/mainline kernels, finish configuring the grub packages, reinstall the latest mainline kernel and be on my marry way.

If it installed unsigned versions alongside the signed ones, then the UKUU kernels removed should have no effect on that. Also, if you can't boot with unsigned kernels no matter what when Secure Boot is on, then how come I don't have to turn it off after reinstalling the mainline kernels and the system boots just fine (and yes, I checked)?

It gives me the impression that Secure Boot only looks at GRUB and doesn't really see the kernels.

Revision history for this message
Jim Aird (jimaird1) wrote :

To Sandi Vujakovic
Is it possible to send me an instruction that I can type into my computer.
I can copy and paste into terminal.
regards Jim Aird
On Fri, 7 Sep 2018 at 21:03, Sandi Vujaković <email address hidden> wrote:
>
> The workaround that I have is removing all UKUU added/mainline kernels,
> finish configuring the grub packages, reinstall the latest mainline
> kernel and be on my marry way.
>
> If it installed unsigned versions alongside the signed ones, then the
> UKUU kernels removed should have no effect on that. Also, if you can't
> boot with unsigned kernels no matter what when Secure Boot is on, then
> how come I don't have to turn it off after reinstalling the mainline
> kernels and the system boots just fine (and yes, I checked)?
>
> It gives me the impression that Secure Boot only looks at GRUB and
> doesn't really see the kernels.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1789107).
> https://bugs.launchpad.net/bugs/1788727
>
> Title:
> upgrade crashing due to unsigned kernels
>
> Status in grub2 package in Ubuntu:
> Confirmed
>
> Bug description:
> not surre happened during upgrade to bionic beaver
>
> ProblemType: Package
> DistroRelease: Ubuntu 18.04
> Package: grub-efi-amd64 2.02-2ubuntu8.3
> Uname: Linux 4.7.0-040700-generic x86_64
> NonfreeKernelModules: nvidia
> ApportVersion: 2.20.9-0ubuntu7.2
> Architecture: amd64
> Date: Thu Aug 23 19:33:07 2018
> ErrorMessage: installed grub-efi-amd64 package post-installation script subprocess returned error exit status 1
> InstallationDate: Installed on 2018-05-30 (85 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.7.0-040700-generic root=UUID=d9d727a6-5798-4fe1-8ac0-fb79b1d05431 ro quiet splash vt.handoff=7
> Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3ubuntu1
> PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1
> RelatedPackageVersions:
> dpkg 1.19.0.5ubuntu2
> apt 1.6.3ubuntu0.1
> SourcePackage: grub2
> Title: package grub-efi-amd64 2.02-2ubuntu8.3 failed to install/upgrade: installed grub-efi-amd64 package post-installation script subprocess returned error exit status 1
> UpgradeStatus: Upgraded to bionic on 2018-08-23 (0 days ago)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1788727/+subscriptions

Revision history for this message
Sandi Vujaković (elsandosgrande) wrote :

Jim, I only know the GUI way of doing it. I select all of the kernels above 4.15.xx and select remove, but only once I have booted up with the older kernel (once the GRUB menu appears, go into Advanced options and look for 4.15 and boot off of that, just don't select "(recovery mode)"), type "apt autoremove", but since you probably don't use the terminal logged in as root in it, type in "sudo apt autoremove" and it should automatically start configuring the packages that were not configured previously, a.k.a. the GRUB updates, open UKUU, install the latest available kernel, restart and enjoy!

Do note that I am using an HP laptop and that a previous GRUB update (a few months ago) enrolled new Secure Boot keys, which might affect the fact that I'm booting with unsigned kernels and Secure Boot on.

Good luck and have a nice day!

Revision history for this message
Jim Aird (jimaird1) wrote :
Download full text (3.7 KiB)

Sandi, I hope this is the correct procedure reporting via you. Thanks
for the email. My HP system seems a little different than yours, I
finished up with the two latest kernels and a warning that I also had
an old kernel that was not of the secure boot (efi) variety.

I deleted the old kernel, to find later that it was the old kernel
that worked best occasional.

I cannot directly install Ubuntu 20.18 from a USB stick, it wont even
load up. I managed to install Ubuntu 17.10 then upgrade to Ubuntu
20.18

The first non efi kernel was 4.13.0-21-generic. I upgraded from Ubuntu
17.10, and am informed that a non efi kernel 4.13.0-46-generic has
appeared and prevents completion, I have deleted this kernel. After
aprox 20 boots I gave up trying to get into the computer. (there is no
logic in getting the computer to boot up, the more I try the less
chance of success).

Next day

Five attempts booting with kernel 4.15.0-3-generic failed, third
attempt with kernel 4.13.0-21-generic success

A crash happened on the HP pc this morning and I was asked if I could
supply any data, hence this email. I hope this information reaches all
concerned and is of use.

Regards Jim
On Wed, 12 Sep 2018 at 00:00, Sandi Vujaković
<email address hidden> wrote:
>
> Jim, I only know the GUI way of doing it. I select all of the kernels
> above 4.15.xx and select remove, but only once I have booted up with the
> older kernel (once the GRUB menu appears, go into Advanced options and
> look for 4.15 and boot off of that, just don't select "(recovery
> mode)"), type "apt autoremove", but since you probably don't use the
> terminal logged in as root in it, type in "sudo apt autoremove" and it
> should automatically start configuring the packages that were not
> configured previously, a.k.a. the GRUB updates, open UKUU, install the
> latest available kernel, restart and enjoy!
>
> Do note that I am using an HP laptop and that a previous GRUB update (a
> few months ago) enrolled new Secure Boot keys, which might affect the
> fact that I'm booting with unsigned kernels and Secure Boot on.
>
> Good luck and have a nice day!
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1789107).
> https://bugs.launchpad.net/bugs/1788727
>
> Title:
> upgrade crashing due to unsigned kernels
>
> Status in grub2 package in Ubuntu:
> Confirmed
>
> Bug description:
> not surre happened during upgrade to bionic beaver
>
> ProblemType: Package
> DistroRelease: Ubuntu 18.04
> Package: grub-efi-amd64 2.02-2ubuntu8.3
> Uname: Linux 4.7.0-040700-generic x86_64
> NonfreeKernelModules: nvidia
> ApportVersion: 2.20.9-0ubuntu7.2
> Architecture: amd64
> Date: Thu Aug 23 19:33:07 2018
> ErrorMessage: installed grub-efi-amd64 package post-installation script subprocess returned error exit status 1
> InstallationDate: Installed on 2018-05-30 (85 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.7.0-040700-generic root=UUID=d9d727a6-5798-4fe1-8ac0-fb79b1d05431 ro quiet splash vt.handoff=7
> Python3Details: /usr/bin/python3.6, Python 3.6.5, python3...

Read more...

Revision history for this message
Sandi Vujaković (elsandosgrande) wrote :

Forewarning, I began switching to Antergos one day after your post and finished today, so I will not be able to provide any more hands-on data, since Antergos is an Arch-based distribution (tried to install Arch in a VM twice, failed both times). I switched because I was trying to make my Ubuntu install into a rolling one, so why not switch to a proper rolling one, like say Arch (or an Arch-based one, like Antergos). I had to disable Secure Boot though, so it defeats the purpose of this bug (yes, it seems that Arch kernels are unsigned), but whatever.

It seems that you misunderstood me, at least a bit. The older kernels are the ones you're not supposed to remove during this procedure. I am not sure about the upgrade being interrupted by the newer kernels, but I didn't try UKUU before 18.04 anyway (speaking of which, did you mean 18.04 when you wrote 20.18?).
Also, the kernels aren't "efi" and "non-efi", they're signed and unsigned, reflecting whether or not they would pass under Secure Boot, though it seems that my laptop doesn't care after GRUB is loaded, which is signed by Canonical as well (speaking of which, what's the model of your laptop? the number should be on the underside of it if it's a newer model, probably 2014 and later, but definitely 2016 and later, mine's 15-aw003nm).

Could you please clarify what your course of action was after installing Ubuntu Artful?

My understanding is that you didn't even touch UKUU (Ubuntu Kernel Update Utility) on Artful before upgrading to Bionic and not even after the upgrade. If that is the case, could you provide a few more details regarding that (the exact or near exact error message, whether or not you have Secure Boot enabled, generally what was going on, ...).
Also, what sort of crash was it? Was it a full system crash or did it affect just a part of the system (also, whether you're using the Ubuntu or Ubuntu on Wayland session, you can check by clicking the cog left of Sign in, since I tend to get an error every time I log into the Xorg session/the default one/the one that is not Wayland on Ubuntu, though not on Antergos oddly enough, and you say it actually prompted for information, which does not happen if it crashes to the extend that some of my experiments made it crash, but only for application crashes and crashes of a similar scale)?

One last thing I just realized. You're replying in an email? How?

Anyway, good luck and have a nice day!

jai (dspace123)
Changed in grub2 (Ubuntu):
assignee: nobody → jai (dspace123)
Revision history for this message
Jim Aird (jimaird1) wrote :
Download full text (7.3 KiB)

Sandi, Answer to your last question first, I am a pensioner, I write
slow, make mistakes, (hence 20.18 should read 18.04), I need a good
spell checker, so I use writer to prepare what I want to say then I
paste it into the email, I must remember to paste as raw text in
future.

The computer that I am having problems with is as follows :-

HP ENVY 15-AH151s 15.6" Laptop - AMD A10-8700P - 8GB Ram - 1TB HDD -
Bang & Olufsen Audio Win10

Sold second hand by Amazon/Luzern, It arrived Saturday, June 25 2016

The computer came with windows 10 installed. My plan was to remove
windows 10 and install Ubuntu 16.04.

I had previously converted three desktop and two laptop PCs to Ubuntu
without any problems, the latter being a Lenovo G50-70 Laptop
converted from window 8 and is now running Ubuntu 18.04

I set the HP Notebook to Legacy Bios and disabled fast boot.

Startup Disk Creator was used to make a boot USB, with witch I used
the “try Ubuntu” option to ensure Ubuntu would run on this machine,
all seemed OK so I started the install procedure. I chose to use the
whole hard disk for Ubuntu as I don’t use Microsoft.

The install went fine, all complete I was instructed to re boot, a
black screen was the result.

I rebooted into setup mode and selected the ubuntu option and got a
screen full of cascading code.

I booted with the USB in the “try Ubuntu” mode, all the Ubuntu file
had been installed but the uefi would not let them load

I took the computer to a computer repair shop, the man said it will be
ready in 24 hours. Five weeks later he gave me the PC back and said it
was something microsoft or HP had done wrong!

Over the months that followed I saw many different screens, Ubuntu
logo, static code, blank screen etc!

I list things I have tried in many combinations (Note, I can copy and
paste code but compiling code is beyond me). Gparted, Boot repair,
Disks, re formatted the hard drive in both MBR and GPT, Legacy Bios
and Secure Boot.

When I click on “disks” I see the following three devices,

1.0 TB Hard Disk WDC WD10JPVX-60JC3TO

1.0 GB Drive Generic Flash Disk, (this is my USB boot drive)

1.5 GB Loop Device /cdrom/casper/filesystem.squashfs

I think the Loop Device is the cause of the problem.

I’ve tried to delete the Loop Device and or the rofs directory but
they won’t let me. I was hoping this would allow me to run Ubuntu in
legacy BIOS mode.

After about a year of trying all sorts to get the computer to work I
sort of gave up.

When the CPU manufactures where found out to have been making faulty
processors the computer manufactures started modifying firmware and
software to get round the problem.

I got my sick laptop out of the cupboard to see if it would work,
after many weeks of trying different ways of installing and trying to
boot Ubuntu it suddenly booted up, but it was several more weeks
before I got it to boot up again.

I never seems to boot up the same way twice, When I managed to get the
machine going occasionally with 17.10 in efi but never in legacy bios
mode.

When I first tried to install 18.04 by usb it would not load but it
did the last time ai tried.

The ratio booting up can be anything between first time an...

Read more...

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

The package shim-signed started to fail like this one in the latest days. I have installed in my computer the following unsigned kernels:

drm-tip (4.19-rc4 with multiple patches);
4.18.6 (Ubuntu mainline)
4.18-rc1 (Ubuntu mainline)
4.17.19 (Ubuntu mainline)
4.17.18 (Ubuntu mainline)
4.17.18 (not a typo, it's another build)

I understand very well why I have this problem, but I have two questions related to this bug:

1) I could install mainline kernels before without this error and the system booted normally with Secure Boot enabled. Is the Secure Boot implementation of my notebook failing?

2) Would it be possible to sign new builds of the mainline kernels at kernel.ubuntu.com/~kernel-ppa/mainline/ ?

Revision history for this message
Steve Kowalik (stevenk) wrote :

I hit this last night, it didn't impact booting, but it did fail the upgrade, which I had to fix up post-reboot with dpkg --configure -a. This should not be necessary. The problem is the *running* kernel from 16.04 is unsigned, and that is what the postinst complains about. I would welcome an SRU to 16.04 adding a signed kernel.

Revision history for this message
josh (freedman-joshua) wrote :

Isn't this a big security issue?

On Tue, Oct 2, 2018 at 12:25 AM Steve Kowalik <email address hidden> wrote:

> I hit this last night, it didn't impact booting, but it did fail the
> upgrade, which I had to fix up post-reboot with dpkg --configure -a.
> This should not be necessary. The problem is the *running* kernel from
> 16.04 is unsigned, and that is what the postinst complains about. I
> would welcome an SRU to 16.04 adding a signed kernel.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1788864).
> https://bugs.launchpad.net/bugs/1788727
>
> Title:
> upgrade crashing due to unsigned kernels
>
> Status in grub2 package in Ubuntu:
> Confirmed
>
> Bug description:
> not surre happened during upgrade to bionic beaver
>
> ProblemType: Package
> DistroRelease: Ubuntu 18.04
> Package: grub-efi-amd64 2.02-2ubuntu8.3
> Uname: Linux 4.7.0-040700-generic x86_64
> NonfreeKernelModules: nvidia
> ApportVersion: 2.20.9-0ubuntu7.2
> Architecture: amd64
> Date: Thu Aug 23 19:33:07 2018
> ErrorMessage: installed grub-efi-amd64 package post-installation script
> subprocess returned error exit status 1
> InstallationDate: Installed on 2018-05-30 (85 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64
> (20160420.1)
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.7.0-040700-generic
> root=UUID=d9d727a6-5798-4fe1-8ac0-fb79b1d05431 ro quiet splash vt.handoff=7
> Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal,
> 3.6.5-3ubuntu1
> PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal,
> 2.7.15~rc1-1
> RelatedPackageVersions:
> dpkg 1.19.0.5ubuntu2
> apt 1.6.3ubuntu0.1
> SourcePackage: grub2
> Title: package grub-efi-amd64 2.02-2ubuntu8.3 failed to install/upgrade:
> installed grub-efi-amd64 package post-installation script subprocess
> returned error exit status 1
> UpgradeStatus: Upgraded to bionic on 2018-08-23 (0 days ago)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1788727/+subscriptions
>

--

Joshua Freedman

CabbyGo, LLC <http://www.freedmancapitalgroup.com/freedmanpublickey.txt>

49 Sample Bridge RD

Mechanicsburg, PA 17050

YouTube <https://www.youtube.com/channel/UCwxROtsN25HbBoYcY0eEXUA>

Twitter: CabbyGo <http://www.twitter.com/CabbyGo>

p:4129513882

Schedule CabbyGo demo or carrier onboarding <https://calendly.com/cabbygo>

PGPKEY <http://www.freedmancapitalgroup.com/freedmanpublickey.txt>

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

This isn't a security issue.

You may have unsigned kernels on your system, but we're planning to have grub enforce signed kernels if Secure Boot is enabled -- therefore we need to catch the case where no kernel is appropriately signed by a key that is known to the firmware or to shim.

There's clearly some issues with the detection (and some limitations) that we're working on addressing right now.

Systems that only have official kernels properly installed should work normally.

Any installs that require custom kernels, or kernels coming from a PPA would likely not be signed (well, they are, but people are unlikely to have the keys installed in firmware), so we need to block upgrade -- it's a better alternative than having your systems fail to boot after the upgrade because we started to install a grub that insists on signed kernels, or because your running kernel is unsigned / not signed by a key that is recognized.

I'm keeping this task open as there's more work needed here to make this a better experience -- we don't /have to/ fail upgrade in all the cases, but it's currently the only thing we can do (and I'm working on improving that).

Changed in grub2 (Ubuntu):
assignee: jai (dspace123) → nobody
status: Confirmed → Triaged
importance: Undecided → High
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

We'll at least address the upgrade process when the same kernel version exists in both the vmlinuz file, and the vmlinuz.efi.signed file. We shouldn't fail and thing this is an unsigned kernel when there's obviously a signed copy of it also on disk, and grub config will use the .efi.signed version.

description: updated
Changed in grub2 (Ubuntu Bionic):
status: New → Triaged
importance: Undecided → High
Changed in grub2 (Ubuntu Cosmic):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 2.02+dfsg1-5ubuntu6

---------------
grub2 (2.02+dfsg1-5ubuntu6) cosmic; urgency=medium

  [ Steve Langasek ]
  * debian/grub-check-signatures: Handle the case where we have unsigned
    vmlinuz and signed vmlinuz.efi.signed. (LP: #1788727)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 03 Oct 2018 14:59:05 -0400

Changed in grub2 (Ubuntu Cosmic):
status: In Progress → Fix Released
Revision history for this message
Bob Colquhoun (bobcolquhoun12) wrote :

Please take me off this list. I have already loaded a new copy of 18.04
wiping out the upgrade.

Thanks

Bob Colquhoun

On 09/10/18 08:54, Launchpad Bug Tracker wrote:
> This bug was fixed in the package grub2 - 2.02+dfsg1-5ubuntu6
>
> ---------------
> grub2 (2.02+dfsg1-5ubuntu6) cosmic; urgency=medium
>
> [ Steve Langasek ]
> * debian/grub-check-signatures: Handle the case where we have unsigned
> vmlinuz and signed vmlinuz.efi.signed. (LP: #1788727)
>
> -- Mathieu Trudel-Lapierre <email address hidden> Wed, 03 Oct 2018
> 14:59:05 -0400
>
> ** Changed in: grub2 (Ubuntu Cosmic)
> Status: In Progress => Fix Released
>

ali reza (alirezasabb)
Changed in grub2 (Ubuntu Cosmic):
assignee: nobody → ali reza (alirezasabb)
Changed in grub2 (Ubuntu Bionic):
status: Triaged → New
Steve Langasek (vorlon)
Changed in grub2 (Ubuntu Bionic):
status: New → Triaged
Changed in grub2 (Ubuntu Cosmic):
assignee: ali reza (alirezasabb) → nobody
Changed in grub2 (Ubuntu Bionic):
assignee: nobody → Sarath P Nath (sarathpnath)
Changed in grub2 (Ubuntu Cosmic):
assignee: nobody → Sarath P Nath (sarathpnath)
Changed in grub2 (Ubuntu Bionic):
status: Triaged → Fix Released
Steve Langasek (vorlon)
Changed in grub2 (Ubuntu Bionic):
assignee: Sarath P Nath (sarathpnath) → nobody
Changed in grub2 (Ubuntu Cosmic):
assignee: Sarath P Nath (sarathpnath) → nobody
Changed in grub2 (Ubuntu Bionic):
status: Fix Released → Triaged
Revision history for this message
Elias Batek (0xeab) wrote :

Maybe signing the mainline kernels (kernel.ubuntu.com/~kernel-ppa/mainline/) could prevent this happening for some users.

Revision history for this message
Steve Langasek (vorlon) wrote :

Those kernels are absolutely not going to be signed with the Ubuntu archive Secure Boot key. They are a separate security domain.

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

Shouldn't this new Ubuntu bootloader refuse to boot unsigned kernels, is this refusal to boot not implemented yet or I understood its goal incorrectly?

In the current state it seems to have no benefits, as I can boot any kernel I want from Ubuntu's bootloader, and cause a lot of trouble with the failing updates.

Revision history for this message
Steve Langasek (vorlon) wrote :

The overall plan is that we ARE updating the bootloader, across all supported Ubuntu releases, to no longer boot unsigned kernels. In various places the upgrade handling to report problems with unsigned kernels has landed before the actual change to the bootloader. This is correct, we certainly wouldn't want things landing in the opposite order and render the user's system unbootable!

So the security benefits are coming, but slowly and in a way that minimizes the impact to the user's system. This specific bug report is simply about a case where we misreport that the kernel will not be bootable, and will be fixed in the next upload.

Revision history for this message
Steve Langasek (vorlon) wrote :

I have marked this a regression-update since the behavior was introduced on bionic in SRU via grub2 2.02-2ubuntu8.3 post-release, and impacts all upgrades from xenial to bionic for secureboot-enabled systems.

tags: added: regression-update
tags: added: id-5bdb73bc573ea205340525bc
Steve Langasek (vorlon)
Changed in grub2-signed (Ubuntu Cosmic):
status: New → Fix Released
Changed in grub2-signed (Ubuntu):
status: New → Fix Released
Steve Langasek (vorlon)
Changed in grub2 (Ubuntu Bionic):
status: Triaged → In Progress
Changed in grub2-signed (Ubuntu Bionic):
status: New → In Progress
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Al, or anyone else affected,

Accepted grub2 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in grub2 (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-bionic
Changed in grub2-signed (Ubuntu Bionic):
status: In Progress → Fix Committed
Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Al, or anyone else affected,

Accepted grub2-signed into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.93.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in grub2 (Ubuntu):
assignee: nobody → Steve figueroa (homecompsg)
Changed in grub2 (Ubuntu Bionic):
assignee: nobody → Steve figueroa (homecompsg)
Changed in grub2 (Ubuntu Cosmic):
assignee: nobody → Steve figueroa (homecompsg)
Changed in grub2-signed (Ubuntu):
assignee: nobody → Steve figueroa (homecompsg)
Changed in grub2-signed (Ubuntu Bionic):
assignee: nobody → Steve figueroa (homecompsg)
Changed in grub2-signed (Ubuntu Cosmic):
assignee: nobody → Steve figueroa (homecompsg)
Steve Langasek (vorlon)
Changed in grub2 (Ubuntu):
assignee: Steve figueroa (homecompsg) → nobody
Changed in grub2 (Ubuntu Bionic):
assignee: Steve figueroa (homecompsg) → nobody
Changed in grub2 (Ubuntu Cosmic):
assignee: Steve figueroa (homecompsg) → nobody
Changed in grub2-signed (Ubuntu):
assignee: Steve figueroa (homecompsg) → nobody
Changed in grub2-signed (Ubuntu Bionic):
assignee: Steve figueroa (homecompsg) → nobody
Changed in grub2-signed (Ubuntu Cosmic):
assignee: Steve figueroa (homecompsg) → nobody
Revision history for this message
Miguel Aveiro (mightymig) wrote :

Hi. Could someone please help me with updating my Ubuntu? I've received these errors.

I'm not a software developer and pretty new to Linux so simple explanations are appreciated.

Thanks.

Revision history for this message
Brian Murray (brian-murray) wrote :

I verified that an upgrade from Ubuntu 16.04 to Ubuntu 18.04 is possible (and that grub did not bail) with -proposed enabled when the kernel you are running also has an .efi.signed file in boot i.e I was running the 4.4.0-139-generic image.

Revision history for this message
Brian Murray (brian-murray) wrote :

I also did receive an unsigned kernels dialog when I had a unsigned version of vmlinuz-4.10.0-28-generic installed.

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 2.02-2ubuntu8.9

---------------
grub2 (2.02-2ubuntu8.9) bionic; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * debian/default/grub.md5sum: add entry for 2.02-2ubuntu8.7; to force an
    update of /etc/default/grub back to the correct timeout value of 0 if the
    file has otherwise not been edited by the user. (LP: #1784363)

  [ Steve Langasek ]
  * debian/grub-check-signatures: Handle the case where we have unsigned
    vmlinuz and signed vmlinuz.efi.signed. (LP: #1788727)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 08 Nov 2018 10:53:28 -0500

Changed in grub2 (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for grub2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2-signed - 1.93.10

---------------
grub2-signed (1.93.10) bionic; urgency=medium

  * Rebuild against grub2 2.02-2ubuntu8.9 (LP: #1784363) (LP: #1788727)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 08 Nov 2018 10:54:58 -0500

Changed in grub2-signed (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Elon Musk (elonmuskles) wrote :

Ho do I install it?

-Download file
-extract
-cd into the folder
-command line: make

thats all?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.