Tracking and Fixing an Installer Bug

不久前，我们的错误跟踪器报告了Kali Linux 1.0.4 中LVM 加密安装的错误。这个错误在我们的TODO 中是高度优先的，因为加密安装是我们行业的一个重要功能，所以我们希望尽快消除这个错误。本文将描述在Kali 中以及最终在Debian 中调试、识别和修复此错误的过程。

这个错误本身很奇怪；使用“LVM 加密”选项安装Kali 将导致安装完成后启动失败:

错误报告中建议的解决方法表明/etc/crypttab 文件为空。通过手动重新挂载加密分区，用所需的参数重新填充它，然后更新initramfs，机器将再次成功启动到加密分区。最令人烦恼的是而且远不实用。

现在问题已经明确，解决方案似乎很简单。在安装过程中更新/etc/crypttab 的方式可能有问题。我们的下一步是调查负责此更新的脚本，看看文件更新过程中是否存在任何错误。但是，您如何找到负责此更新的确切脚本以及我们如何找出它位于哪个包中？

DebianInstaller 来拯救我们了。使用这组脚本，我们检查了整个DebianInstaller 源代码树。这将使我们能够更轻松地搜索影响/etc/crypttab 的脚本:

root@kalima:~# svn co svn://anonscm.debian.org/svn/d-i/trunk debian-installer

root@kalima:~# cd debian-installer

root@kalima:~/debian-installer# 脚本/git-setup

root@kalima:~/debian-installer# mr -p checkout

签出所有存储库后，我们可以简单地grep 查找引用/etc/crypttab 文件的任何文件，如下所示:

root@kalima:~/debian-installer# grep -r '/etc/crypttab' * |grep -v ^手册

.

packages/partman-crypto/finish.d/crypto_config:# dm-crypt: 创建/etc/crypttab 条目

packages/partman-crypto/finish.d/crypto_config: echo '$target $source $keyfile $opts' /target/etc/crypttab

.

root@kalima:~/debian-installer#

我们在上面看到它是写入/etc/crypttab 的“crypto_config”脚本，该脚本位于partman-crypto包中。

理想情况下，我们希望调试此脚本并查看问题出在哪里，但如何在实时安装媒体中执行此操作？答案相对简单- 我们只需在安装过程中弹出命令提示符即可。诀窍是在安装的正确阶段调用我们的调试shell（通过按CTRL+ALT+F2） - 在我们的例子中，我们需要在运行crypto_config 脚本之前但在安装partman-crypto udeb 之后中断安装程序，因此分区过程的开始将是一个好时机。我们继续编辑/lib/partman/finish.d/55_crypto_config 并在脚本的开头添加“set -x”:

然后我们让安装程序完成它的工作，就在安装完成之前，我们在另一个shell 中查看了/var/log/syslog。令我们惊讶的是，我们看到/etc/crypttab 文件*正在* 被更新，这与我们最初的想法相反，如安装的系统日志中所示。 WTH:

8月28日21:57:42主菜单[954]:（process:9810）: crypttab_add_entry

8月28日21:57:42 主菜单[954]: (process:9810): /dev/sda5

8月28日21:57:42主菜单[954]:（process:9810）: /var/lib/partman/devices/=dev=sda/256901120-160041009151

8月28日21:57:42 主菜单[954]: (process:9810): /dev/mapper/sda5_crypt

.

8月28日21:57:42主菜单[954]:（process:9810）:回显

8月28日21:57:42主菜单[954]:（process:9810）: sda5_crypt UUID=6250dbca-648b-4848-9132-cfa900ab5874无luks

这就是我们开始摸不着头脑的地方。如果问题不在于这个文件的写入（正如我们预期的那样），那么为什么安装后会出现一个空的/etc/crypttab 文件？也许问题根本不在于partman-crypto，而在于live-build如何生成我们的ISO？我们使用Kali 迷你安装ISO（不是通过实时构建构建）测试了我们的理论，并注意到LVM 加密安装在使用该安装介质时工作正常。

我们知道实时安装程序使用tar 将整个实时文件系统复制到已安装的/target 目录中，并假设文件系统是空的，这基本上是正确的，因为它们是由partman创建的。这意味着任何预先存在的文件如果也在实时映像中，则可以被覆盖，在本例中/etc/crypttab 就发生了这种情况。

进一步检查发现问题出在实时安装程序中，它覆盖了生成的/etc/crypttab。实时安装程序已经有一些不覆盖/etc/fstab 的规定，因此只需概括该规则并包含/etc/crypttab 文件即可:

$ diff --git a/debian/live-installer.postinst b/debian/live-installer.postinst

索引9a39d8d.bc40b84 100644（文件）

--- a/debian/live-installer.postinst

+++ b/debian/live-installer.postinst

@@ -8,6 +8,8 @@ db_capb 备份

# 架构和操作系统检测

ARCH=`udpkg --打印架构`

操作系统=`udpkg --print-os`

+# 不得被实时系统副本覆盖的文件

+FILES_TO_PRESERVE='/etc/fstab /etc/crypttab'

换行='

'

@@ -34,11 +36,12 @@ install_live_system () {

# 那里有符号链接。

rmdir /target/var/lock /target/var/run 2/dev/null ||真实

- # 备份预先存在的/etc/fstab，因为它将被覆盖

- # 实时系统的副本

- 如果[ -e /target/etc/fstab ] [ ! -e /target/etc/fstab.live-installer ];那么

- mv /target/etc/fstab /target/etc/fstab.live-installer

-fi

+ # 备份不应被副本覆盖的文件

+ for f in $FILES_TO_PRESERVE;做

+ if [ -e /target$f ] [ ! -e /target/${f}.live-installer ];那么

+ mv /target$f /target${f}.live-installer

+fi

+ 完成

对于$PLACES 中的位置；做

[ ！ -e $place ] 继续

@@ -83,10 +86,12 @@ install_live_system () {

评估${SUPPORT}_teardown

完成

- # 恢复d-i创建的fstab文件

- 如果[ -e /target/etc/fstab.live-installer ];那么

- mv /target/etc/fstab.live-installer /target/etc/fstab

-fi

+ # 恢复重要配置文件

+ for f in $FILES_TO_PRESERVE;做

+ if [ -e /target${f}.live-installer ];那么

+ mv /target${f}.live-installer /target$f

+fi

+ 完成

如果[ ${PLACE_FOUND} -eq 0 ];那么

错误“找不到任何实时图像”

上述补丁为我们解决了这个问题，允许加密的LVM 安装完成并成功启动。与我们遇到的任何Debian 错误一样，我们会将补丁发送回Debian，以改进我们构建的发行版。此安装程序错误的修复将在下周的下一个版本(1.0.5) 中发布。人们通过实时构建生成自己的ISO 映像将自动收到固定包。