CentOS 重啟後 LVM 卷處於非活動狀態
我已經從 CentOS 6 到 7 重新安裝了 Linux 伺服器。該伺服器有 3 個驅動器 - 一個系統 SSD 驅動器(它承載除 之外的所有東西
/home
)和兩個承載/home
. 一切都使用LVM。兩個 4TB 驅動器被鏡像(使用 LVM 本身的 raid 選項),它們完全被 /home 分區填充。問題是,雖然 4TB 磁碟被辨識得很好,並且 LVM 看到該卷沒有問題,但它並沒有自動啟動它。其他一切都會自動啟動。我可以手動啟動它,它可以工作。
我在 /home 中有舊系統驅動器的映像。這也包含 LVM 卷。如果我用 安裝它
kpartx
,LVM 會拾取並啟動它們。但我看不出這些捲和非活動卷之間沒有區別。根文件系統也是 LVM,並且可以很好地啟動。
不過,我看到了一件奇怪的事情:執行
lvchange -aay
告訴我需要指定要啟動的驅動器。它也不會自動執行。如果我指定lvchange -ay lv_home
- 那行得通。我找不到任何可能對這種行為負責的東西。
**補充:**我注意到舊系統(使用init)
vgchange -aay --sysinit
在其啟動腳本中有。新的使用 systemd,我沒有vgchange
在它的腳本中看到呼叫。但我也不知道該放在哪裡。**補充2:**開始搞清楚systemd。我找到了腳本所在的位置並開始了解它們是如何被呼叫的。還發現我可以看到執行的腳本
systemctl -al
。這向我表明,在啟動後lvmetad
它會呼叫pvscan
每個已知的 udev 塊設備。但是,此時只有一個已註冊的 udev 塊設備,這是可辨識的 lvm 卷之一。硬碟驅動器也在那裡,但使用不同的路徑和更長的名稱。公認的塊設備有點像8:3
,而硬碟也有點像/device/something/
。我不再在伺服器上,所以我不能準確地寫它(稍後會解決這個問題)。我認為它與 udev 和設備檢測/映射有關。我會在晚上繼續學習udev。
如果一切都失敗了,我找到了呼叫的腳本
pvscan
並檢查了我可以修改它以一直掃描所有設備。這解決了問題,但它看起來像一個相當醜陋的黑客,所以我會嘗試找出真正的根本原因。補充3:好的,我仍然不知道為什麼會發生這種情況,但至少我已經做了一個相當可行的解決方法。我創建了另一個 systemd 服務,它在啟動後立即呼叫
pvscan
一次lvmetad
。對特定設備的另一個呼叫仍然存在,我認為它實際上udev
是呼叫它(這是我找到引用它的唯一地方)。為什麼它不為其他硬碟呼叫它 - 我不知道。
我做到了!我做到了!我正確地修復了它(我認為)。
這是故事:
一段時間後,伺服器出現故障,不得不報廢。我保留了磁碟並獲得了其他一切新的東西。然後我在 SSD 上重新安裝了 CentOS,然後我連接了 HDD。LVM 執行良好,磁碟被辨識,配置被保留。但同樣的問題再次出現 - 重新啟動後,該卷處於非活動狀態。
然而這一次我偶然注意到了一些別的東西——引導載入程序將以下參數傳遞給核心:
crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet
嗯,等一下,那些看起來很熟悉!
快速Google查詢,我們有:
rd.lvm.lv=
僅啟動具有給定名稱的邏輯卷。rd.lvm.lv 可以在核心命令行上多次指定。
現在好了。這解釋了它!
所以,決議是(從幾個Google查詢中收集的):
- 修改
/etc/defaults/grub
以在參數中包含附加卷:crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap
rd.lvm.lv=vg_home/lv_home
rhgb quiet
- 重新配置grub
grub2-mkconfig -o /boot/grub2/grub.cfg
- 重新配置 initramfs 與
mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64
. **注意:**您的值可能會有所不同。用於uname -r
獲取該核心版本。或者只是繼續閱讀mkinitrd
。(坦率地說,我不知道為什麼需要這一步,但顯然它是 - 我試過沒有它但它沒有用)- 最後,重新安裝 grub:
grub2-install /dev/sda
- 重啟,自然。
達達!卷在重新啟動時處於活動狀態。添加到
fstab
並享受!:)