8

I need to compile and install my own bionic kernels to fix a typo in xhci-pci.c

I've done this successfully in the past, as late as 18.04 I think, following the instructions at:

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

But now when I try to install my new kernels (and test kernels from devs trying to help me run the fix up the flagpole) dpkg -i complains and it seems my changes aren't reflected on reboot. How do I fix this?

UPDATE: Installing the kernel I compiled on my desktop onto a different server seems to work. I speculate this is because the kernel version running on the server was a few minor revisions behind that running on the desktop. I think the minor revision number running on the desktop is the same I'm attempting to compile and install. Oppositely, the test kernel provided by the devs are some minor revisions behind that of my desktop and server. Whereas previously I placed the blame on "unsigned" packages, now I'm thinking the problem lies with dpkg. How do I force dpkg to install over "conflicting" packages? How do I force it to install a retrograde kernel?

The errors (on the desktop system) are as follows:

dpkg: regarding linux-image-unsigned-4.15.0-29-generic_4.15.0-29.31+jeff_amd64.deb containing linux-image-unsigned-4.15.0-29-generic:
 linux-image-unsigned-4.15.0-29-generic conflicts with linux-image-4.15.0-29-generic
  linux-image-4.15.0-29-generic (version 4.15.0-29.31) is present and installed.

dpkg: error processing archive linux-image-unsigned-4.15.0-29-generic_4.15.0-29.31+jeff_amd64.deb (--install):
 conflicting packages - not installing linux-image-unsigned-4.15.0-29-generic
dpkg: regarding linux-image-unsigned-4.15.0-29-lowlatency_4.15.0-29.31+jeff_amd64.deb containing linux-image-unsigned-4.15.0-29-lowlatency:
 linux-image-unsigned-4.15.0-29-lowlatency conflicts with linux-image-4.15.0-29-lowlatency
  linux-image-4.15.0-29-lowlatency (version 4.15.0-29.31) is present and installed.

dpkg: error processing archive linux-image-unsigned-4.15.0-29-lowlatency_4.15.0-29.31+jeff_amd64.deb (--install):
 conflicting packages - not installing linux-image-unsigned-4.15.0-29-lowlatency
George Udosen
  • 36,677

3 Answers3

3
apt-get remove linux-image-4.15.0-29-lowlatency

say no, you don't wish to abort removing your running kernel so it gets removed. Then 

dpkg -i $new-kernel+jeff

will succeed.

abu_bua
  • 10,783
Hal
  • 31
  • 2
  • In my case it turned out that I had accidentally tried to install the wrong kernel version prior to downloading the right one, Removing the old, partially installed one fixed my problem. – Stonecraft Nov 10 '18 at 12:16
2

Your speculation is mostly correct. There are two types of packages for kernel images, signed and unsigned. If you compile your own kernel, the kernel image won't be signed and will be packaged into a deb named linux-image-unsigned-<version>-generic, while packages with signed images go like linux-image-<version>-generic and are the default choice for kernel images in Ubuntu. It seems that only signed kernel images can pass Secure Boot.

The important thing to note here is that the package linux-image-unsigned-<version>-generic mutually conflicts with linux-image-<version>-generic with the same <version>. See for yourself, where <version> = 5.4.0-65. Pay special attention to the "Conflicts" field.

> apt show linux-image-5.4.0-65-generic
Package: linux-image-5.4.0-65-generic
Version: 5.4.0-65.73
Built-Using: linux (= 5.4.0-65.73)
Priority: optional
Section: kernel
Source: linux-signed
Origin: Ubuntu
Maintainer: Canonical Kernel Team <kernel-team@lists.ubuntu.com>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 11.7 MB
Provides: aufs-dkms, fuse-module, ivtv-modules, kvm-api-4, linux-image, redhat-cluster-modules, spl-dkms, spl-modules, virtualbox-guest-dkms, virtualbox-guest-modules, zfs-dkms, zfs-modules
Depends: kmod, linux-base (>= 4.5ubuntu1~16.04.1), linux-modules-5.4.0-65-generic
Recommends: grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo, initramfs-tools | linux-initramfs-tool
Suggests: fdutils, linux-doc | linux-source-5.4.0, linux-tools, linux-headers-5.4.0-65-generic
Conflicts: linux-image-unsigned-5.4.0-65-generic
Download-Size: 8,898 kB
APT-Sources: http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
Description: Signed kernel image generic
 A kernel image for generic.  This version of it is signed with
 Canonical's UEFI/Opal signing key.

With that knowledge at hand, it's pretty easy to decode the original error message. The first error message

dpkg: regarding linux-image-unsigned-4.15.0-29-generic_4.15.0-29.31+jeff_amd64.deb containing linux-image-unsigned-4.15.0-29-generic:
 linux-image-unsigned-4.15.0-29-generic conflicts with linux-image-4.15.0-29-generic
  linux-image-4.15.0-29-generic (version 4.15.0-29.31) is present and installed.

simply states that two types of packages for kernel images conflict, where <version> = 4.15.0-29. It's impossible to install the unsigned one when the signed one has already been installed. The second error message warns the same thing about another version of package.

Now for the solution part. You can safely uninstall linux-image-4.15.0-29-generic first and then install linux-image-unsigned-4.15.0-29-generic_4.15.0-29.31+jeff_amd64.deb. More generally, to install linux-image-unsigned-<version>-generic, uninstall linux-image-<version>-generic with corresponding <version> first.

But sometimes things are not so easy. In my case, I can't uninstall the signed package because it's a dependency of the meta package linux-image-generic. That meta package always depends on the latest kernel image package and it is a dependency of linux-generic, which is a meta package that pulls in a complete kernel installation (its dependency tree). To uninstall the signed package, I have to also remove linux-image-generic and linux-generic, which may cause problems with updates.

skyfiretime
  • 21
-1

Your Deb package has identical files that conflict with older same-named package. You should remove old package or, maybe, change version settings in the debian folder when you compile the kernel. That might uniquify file names. But tough to predict. I would remove old conflicting kernel.

Remember that kernel you already have was built at factory in a safe environment. One you built probably differs meaningfully because it takes note of stuff your system has, maybe even different compiler and dpkg building strategy. The one yoh build, even with source package from original system, will not be interchangeable.

pauljohn32
  • 3,743