起因

前段时间折腾 LVM on LUKS 差不多有一周的时间。

一直卡在安装 Boot Loader 那一步 (Boot Loader 使用是 GRUB)。

别问我为啥不用其它的 Boot Loader。

因为只有 GRUB 能 加密/解密 /boot 分区

直到有人在论坛上求助了和我同样的问题,才得以解决:

LVM on LUKS, grub-mkconfig hangs - grub-probe gives error

也别问我为啥不去论坛求助。

因为密码数据库存放在电脑中, 电脑又开不了机,我又能怎样呢。

事后也没想到居然被这个小问题折腾了近一周的时间。

后来在 #archlinux-cn 群组里看到 @Xuanwo 说:

定位一个 Bug 的 Upstream Commit 只要 15 分钟左右。

看吧,这就是大佬。

马后炮

再回过头来分析分析这个问题。

Bug or Feature

首先得确认这是一个 Bug,还是一个 Feature。 因为有的 Feature 看着还真的很 Bug。

一般来说影响正常使用的问题都可以视为 Bug。

上面这个问题,还真是一个 Feature 引发的 — [lvm2] LVM need access to /run/lvm under new root

确定问题源

然后就是确认问题的源头。

对于上面这个问题,咋一看的确是 GRUB 的问题。 但事实真的如此吗?

由于是在 grub-mkconfig 这一步报错,所以 GRUB 嫌疑最大。

但是报错信息是:

WARNING: Device /dev/loop0 not initialized in udev database even after waiting 10000000 microseconds.

看起来 /dev 设备有些问题,所以暂时排除 GRUB, 很可能是 LVM 或者 LUKS 设备有问题。

vgscan -v 一下,报错信息为:

WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Reading all physical volumes. This may take a while...
WARNING: Device /dev/loop0 not initialized in udev database even after waiting 10000000 microseconds.

嗯,看来就是 LVM 的问题。

解决问题

俗话说 条条大路通罗马, 很多问题都可以有多个正确解。

这个问题也如此,这就很考验 解决问题 的能力了。

对于这个问题不限于有以下几种解决方案。

  • LVM
    • 改进这个 Feature
  • GRUB
    • 反省自己,为啥别人家的 Boot Loader 没事,就你有事 (依赖自动检测脚本?)
  • Arch-Install-Scripts
    • 帮用户完成 “mount –bind” 操作

当然,别人的 Feature 哪能自己背锅解决, 所以最后还是得用户自己动手解决 (这也算用户中心吗?) — Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds

定位 Upstream Commit

我认为这一步是最难的, 因为不仅需要扎实的编程能力, 也得熟悉相关软件的开发。

限于我的水平, 也只能分析一下这个问题如何定位到 Upstream Commit。

既然上面已经找到是 LVM 的问题, 而出现这个问题时 Wiki 和 Forums 都还没人指出。

所以可以确定是 lvm2 当前的版本 (即 2.02.183-1) 有问题。

那么就可以把 Commit 的范围限定在 2.02.182-12.02.183-1 这两个版本发布的时间之内。

然后就浏览这个时间段内的 Commit, 如果有相关的知识储备的话,那么就能定位到具体的 Commit 了 — devs: use udev info to improve md component detection

反正就是不断用得到的条件, 尽可能的将筛选范围缩减到最小。

后记

马后炮式的分析当然很箭单。

所以,还得继续努力呀。