起因

前段時間折騰 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

反正就是不斷用得到的條件, 儘可能的將篩選範圍縮減到最小。

後記

馬後炮式的分析當然很箭單。

所以,還得繼續努力呀。