kali 版本号 (kali1-5) 之间有什么区别？

Question

uname -r在我的系统上的输出是4.19.0-kali1-amd64. 我在存储库列表中注意到有多个，linux-image-4.19.0-kali#每个都有不同的编号，从 kali1 到 kali5。

这个数字有什么意义？为什么这些数字中的一些没有所有版本的包？可以换号吗？

有关更多上下文：最近对我的 vmware-workstation 的更新正在linux-headers-4.19.0-kali1-amd64我的系统上寻找 ，但这些在存储库中无处可寻。我可以找到 kali3、4 和 5 的这些图像。

Answer 1

它是从 Debian 复制的。在 Debian 上，数字的变化，例如从4.19.0-4-amd64到4.19.0-5-amd64意味着打包者声明（内部内核）ABI 有变化，需要例如重新编译外部模块。当没有完成 ABI 更改时，内核更新会在之前的位置完成，并且其所有模块都将更新到较新的版本。虽然需要重新启动才能使用新内核，但即使以前未加载的模块也已可用于新版本。由于 ABI 保持不变，因此外部模块不会有任何区别。

因此，假设您有模块nat-rtsp-dkms需要像任何 DKMS 模块一样从源代码构建。如果内核升级被认为不会破坏 ABI，则不必重新构建此模块。如果现在升级被认为破坏了 ABI，则名称的更改（暗示来自元包linux-image-amd64的依赖项）将安装一个新的内核版本，这将触发此外部模块的重新编译。这同样适用于 VMware 的外部内核模块。

来自最近的linux-image-amd64 更新日志：

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

取决于实际的linux-image-4.19.0-kali5-amd64，其更改日志记录 ABI 更改，有时会解释原因。以下是一些摘录，并解释了最后一部分对 ABI 2 的更改：

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
    from
  * 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

请注意，linux-header-*包来自相同的来源，因此与linux-image-*包同步。您通常必须替换相关的linux-headers-*包以使其与目标内核匹配才能成功构建外部模块。对于未打包的外部模块（其中一些，可能是 VMware 的，只查看当前运行的内核而不是目标内核），情况仍然如此。

如果再也找不到 Kali 软件包（由于snapshot.debian.org在 Debian 上不会真正发生这种情况），您可以将内核升级到头文件和内核都可用的通用版本：您应该同时安装两者linux-image-4.19.0-kali5-amd64和linux-headers-4.19.0-kali5-amd64（可能在构建前重启，让 VMware 高兴）。如果您构建自己的内核，请不要忘记同时构建相关的linux-headers-包。

如果尽管如此，在重新启动到较新的内核后，VMware 确实坚持使用特定的 kali1 而不是与正在运行的内核匹配的那个，那么您就走运了，必须等待 VMware 的更新或找到解决方法。