This bug was fixed in the package dkms - 2.2.0.3-2ubuntu11.6
---
dkms (2.2.0.3-2ubuntu11.6) xenial; urgency=medium
* debian/patches/shim_secureboot_support.patch:
- Move to signing just after module build to ensure it correctly applies
at kernel update times. (LP:
This bug was fixed in the package dkms - 2.2.0.3-1.1ubuntu5.14.04.10
---
dkms (2.2.0.3-1.1ubuntu5.14.04.10) trusty; urgency=medium
* debian/patches/shim_secureboot_support.patch:
- Move to signing just after module build to ensure it correctly applies
at kernel update
Re-verified trusty since the previous trusty comment was imprecise:
dkms 2.2.0.3-1.1ubuntu5.14.04.10
Upgrading kernel and headers follows with a loadable, properly signed
module using the MOK generated previously.
ubuntu@ubuntu:~$ dpkg -l shim-signed dkms | cat
Verification-done on xenial:
dkms 2.2.0.3-2ubuntu11.6
Upgraded kernel to hwe kernel, drivers can still be loaded from the
right versioned directory for the kernel and loads succesfully --
signature is validated fined as the kernel module is signed.
ubuntu@ubuntu:~$ dpkg -l shim-signed dkms |
Verification-done on trusty:
dkms/2.2.0.3-1.1ubuntu5.14.04.10
I've installed bbswitch on a test UEFI system, upgraded the kernel to a
newer version (ie. linux-image-hwe-trusty-generic) and was still able to
load the module in; the module in the updates/dkms directory for the
kernel version is
Hello Dan, or anyone else affected,
Accepted dkms into trusty-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/dkms/2.2.0.3-1.1ubuntu5.14.04.10 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
Hello Dan, or anyone else affected,
Accepted dkms into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/dkms/2.2.0.3-2ubuntu11.6 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
This bug was fixed in the package dkms - 2.3-3ubuntu9.1
---
dkms (2.3-3ubuntu9.1) bionic; urgency=medium
* 0009-Add-support-for-UEFI-Secure-Boot-validation-toggling.patch: move sign
code to dkms script itself, so it also applies on kernel upgrades.
(LP: #1772950)
--
Verification-done on bionic:
ii dkms 2.3-3ubuntu9.1
all Dynamic Kernel Module Support Framework
ii virtualbox-dkms5.2.10-dfsg-6
all x86 virtualization solution -
** Tags added: id-5b05a00120e543dc26a03df7
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1772950
Title:
dkms key enrolled in mok, but dkms module fails to load
Status in dkms package
** Tags added: id-5b0593ddfc4d344a05f862a7
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1772950
Title:
dkms key enrolled in mok, but dkms module fails to load
Status in dkms package
Hello Dan, or anyone else affected,
Accepted dkms into bionic-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/dkms/2.3-3ubuntu9.1 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
This bug was fixed in the package dkms - 2.3-3ubuntu10
---
dkms (2.3-3ubuntu10) cosmic; urgency=medium
* 0009-Add-support-for-UEFI-Secure-Boot-validation-toggling.patch: move sign
code to dkms script itself, so it also applies on kernel upgrades.
(LP: #1772950)
-- Mathieu
** Description changed:
+ [Impact]
+ All Ubuntu users for whom Secure Boot is enabled.
+
+ [Test cases]
+ 1) install dkms module (use virtualbox-dkms for example)
+ 2) Upgrade kernel (for example, install 4.15.0-22-generic on top of
4.15.0-20-generic).
+ 3) Verify that the generated module for
** Changed in: dkms (Ubuntu)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1772950
Title:
dkms key enrolled in mok,
I can confirm that the new module isn't signed at all:
$ hexdump -Cv /lib/modules/4.15.0-22-generic/updates/dkms/vboxdrv.ko | tail -n
100 | pastebinit
http://paste.ubuntu.com/p/BFSg9DsqR8/
Contrast with a previous kernel that was installed when virtualbox was
last upgraded:
$ hexdump -Cv
The dkms package's shim integration only happens in
/usr/lib/dkms/common.postinst. It appears this code is only triggered
on installation of a dkms package; this code path is not used as part of
the kernel postinst hook when building modules for a newly-installed
kernel - that hook only calls
Based on timestamp info provided out of band,
/lib/modules/4.15.0-22-generic/updates/dkms/vboxdrv.ko was generated as
part of the kernel install via /etc/kernel/postinst.d/dkms, despite the
lack of verbosity.
** Changed in: dkms (Ubuntu)
Status: Incomplete => New
** Changed in: dkms
The logs show the new kernel being installed, but show no dkms module
building at time of kernel install. That seems strange to me. We
should figure out what generated
/lib/modules/4.15.0-22-generic/updates/dkms/vboxdrv.ko and when and why
it's not correctly signed.
** Changed in: dkms (Ubuntu)
term.log for installation of my current kernel:
https://paste.ubuntu.com/p/3TVVFpFSNX/
term.log from the last time I see virtualbox DKMS stuff happening:
https://paste.ubuntu.com/p/7f7p6t48pn/
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
20 matches
Mail list logo
