The output of uname -r on my system is 4.19.0-kali1-amd64. I notice at the repository listing that there are multiple linux-image-4.19.0-kali# each with a different number, from kali1 to kali5.

What is the significance of this number? And why do some of these numbers not have all versions packages? Is it possible to switch number?

For more context: A recent update to my vmware-workstation is looking for the linux-headers-4.19.0-kali1-amd64 on my system but these are nowhere to be found in the repositories. I can find these images for kali3, 4 and 5.


It's copying this from Debian. On Debian a change in number, eg from 4.19.0-4-amd64 to 4.19.0-5-amd64 means the packager declares there is a change in (internal kernel) ABI requiring for example recompiling external modules. When no ABI change is done, the kernel update is done in place over the previous and all of its modules will be updated to the newer version. While a reboot is needed to use the new kernel, even not previously loaded modules would already be available with the new version. The external modules won't see a difference because the ABI stays the same.

So suppose you have the module nat-rtsp-dkms requiring to be built from source like any DKMS module. If there's an upgrade to the kernel deemed not breaking the ABI, this module won't have to be rebuilt. If now the upgrade is considered breaking the ABI, the change in name (implied by a dependency from the meta package linux-image-amd64) will install a new kernel version which will trigger a recompilation of this external module. The same applies to VMware's external kernel modules.

From recent's linux-image-amd64 changelog:

linux-latest (105+kali1) kali-experimental; urgency=medium

  * Sync with Debian
  * Rebuild for 4.19.0-kali5

 -- Sophie Brun <sophie@offensive-security.com>  Thu, 09 May 2019 11:01:17 +0200

linux-latest (105) unstable; urgency=medium

  * Update to 4.19.0-5

 -- Ben Hutchings <ben@decadent.org.uk>  Tue, 07 May 2019 16:33:50 +0100

depending upon actual linux-image-4.19.0-kali5-amd64, where its changelog notes ABI changes, and sometimes explains the reason. Here are some extracts with an explaination for the change to ABI 2 in the last part:

linux (4.19.37-2kali1) kali-experimental; urgency=medium

  * Sync with Debian

 -- Sophie Brun <sophie@offensive-security.com>  Wed, 15 May 2019 09:08:08 +0200

linux (4.19.37-2) unstable; urgency=high

  * debian/bin: Fix Python static checker regressions (Closes: #928618)


linux (4.19.37-1kali1) kali-experimental; urgency=medium

  * Sync with Debian

 -- Sophie Brun <sophie@offensive-security.com>  Thu, 09 May 2019 10:41:49 +0200

linux (4.19.37-1) unstable; urgency=medium


 [ Ben Hutchings ]
  * debian/bin/abiupdate.py: Automatically select the correct archive to fetch
  * debian/bin/abiupdate.py: Change default URLs to use https: scheme
  * [powerpc*] vdso: Make vdso32 installation conditional in vdso_install
    (Closes: #785065)
  * Bump ABI to 5


linux (4.19.16-1kali1) kali-experimental; urgency=medium

  * Sync with Debian

 -- Sophie Brun <sophie@offensive-security.com>  Mon, 21 Jan 2019 13:41:42 +0100

linux (4.19.16-1) unstable; urgency=medium


  [ Yves-Alexis Perez ]
  * Bump ABI to 2 because of changes in struct sock_common from 60f05dddf1eb

Note that linux-header-* packages are from the same source and thus in sync with the linux-image-* packages. You usually have to replace the relevant linux-headers-* package to have it match the target kernel to be able to build successfully external modules. This stays true for non-packaged external modules (and some of them, possibly VMware's, only look at the current running kernel rather than a target kernel).

If the Kali package can't be found anymore (which wouldn't really happen on Debian because of snapshot.debian.org), you can instead upgrade the kernel to a common version where both headers and kernel are available: you should install both linux-image-4.19.0-kali5-amd64 and linux-headers-4.19.0-kali5-amd64 (and possibly reboot before building, for VMware to be happy). If you build your own kernel, don't forget to keep the associated linux-headers- package built at the same time.

If despite all of this, after the reboot to the newer kernel VMware really insists on the specific kali1 rather than the one matching the running kernel, you're out of luck and have to wait for an update from VMware or find a workaround.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.