我在我的旧电脑上运行 lvm raid1。
- pv:/dev/sda1 sdb1 sdc1
- vg:我的vg
- lv:myvg/debian
根分区是 myvg/debian,它是 sdb1 和 sdc1 上的 raid1。(lvcreate --type raid1 -L 6G --name debian myvg /dev/sdb1 /dev/sdc1
)
今天,系统显示
[ 4.617444] device-mapper: raid: Failed to read superblock of device at position 1
在启动时。
登录后,我看到 raid1 lv 的部分标签为丢失的在/dev/mapper
:
root@home1:/dev/mapper# ls myvg-debian*
myvg-debian myvg-debian_rmeta_0
myvg-debian_rimage_0 myvg-debian_rmeta_1
myvg-debian_rimage_1 myvg-debian_rmeta_1-missing_0_0
myvg-debian_rimage_1-missing_0_0
lsblk
显示debian_r{image,meta}_0
仍在/dev/sdb1
。仅缺少debian_r{image,meta}_1
in /dev/sdc1
,系统仍可启动。
sdb 8:16 0 37.3G 0 disk
└─sdb1 8:17 0 37.3G 0 part
├─myvg-debian_rmeta_0 254:0 0 4M 0 lvm
│ └─myvg-debian 254:6 0 6G 0 lvm /
└─myvg-debian_rimage_0 254:1 0 6G 0 lvm
└─myvg-debian 254:6 0 6G 0 lvm /
我无法使用 lvm 相关工具找到其他错误消息,lvdisplay 和 lvs 的输出看起来不错。
root@home1:/dev/mapper# lvs myvg/debian
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
debian myvg rwi-aor-r- 6.00g 100.00
root@home1:/dev/mapper# lvdisplay myvg/debian-a myvg/debian_r{image,meta}_1
--- Logical volume ---
LV Path /dev/myvg/debian
LV Name debian
VG Name myvg
LV UUID ICBMVi-VVUl-ICAg-CAgI-AgIC-gICA-IDVKaU
LV Write Access read/write
LV Creation host, time home1, 2023-03-04 21:13:03 +0800
LV Status available
# open 1
LV Size 6.00 GiB
Current LE 1536
Mirrored volumes 2
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:6
--- Logical volume ---
Internal LV Name debian_rmeta_1
VG Name myvg
LV UUID JCBMVi-VVUl-ICAg-CAgI-AgIC-gICA-IDVKaU
LV Write Access read/write
LV Creation host, time home1, 2023-03-05 22:42:11 +0800
LV Status available
# open 1
LV Size 4.00 MiB
Current LE 1
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:3
--- Logical volume ---
Internal LV Name debian_rimage_1
VG Name myvg
LV UUID KCBMVi-VVUl-ICAg-CAgI-AgIC-gICA-IDVKaU
LV Write Access read/write
LV Creation host, time home1, 2023-03-05 22:42:11 +0800
LV Status available
# open 1
LV Size 6.00 GiB
Current LE 1536
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:5
pv、vg、lv 扫描也都显示良好:
root@home1:/dev/mapper# pvscan
PV /dev/sda1 VG myvg lvm2 [<120.00 GiB / 5.58 GiB free]
PV /dev/sdb1 VG myvg lvm2 [<37.25 GiB / 1.99 GiB free]
PV /dev/sdc1 VG myvg lvm2 [<233.25 GiB / <187.24 GiB free]
Total: 3 [<390.49 GiB] / in use: 3 [<390.49 GiB] / in no VG: 0 [0 ]
root@home1:/dev/mapper# vgscan
Found volume group "myvg" using metadata type lvm2
root@home1:/dev/mapper# lvscan -a
ACTIVE '/dev/myvg/swap' [3.72 GiB] inherit
ACTIVE '/dev/myvg/debian' [6.00 GiB] inherit
ACTIVE '/dev/myvg/debian_rmeta_0' [4.00 MiB] inherit
ACTIVE '/dev/myvg/debian_rmeta_1' [4.00 MiB] inherit
ACTIVE '/dev/myvg/debian_rimage_1' [6.00 GiB] inherit
ACTIVE '/dev/myvg/debian_rimage_0' [6.00 GiB] inherit
lvchange syncaction 检查也没有报告:
root@home1:/dev/mapper# lvchange --syncaction check myvg/debian
root@home1:/dev/mapper# lvchange --syncaction repair myvg/debian
root@home1:/dev/mapper#
但实际上我无法读取/dev/myvg/debian_rimage_1
。读取时它返回 IO 错误:
root@home1:/dev/mapper# dumpe2fs myvg-debian_rimage_1
dumpe2fs 1.46.2 (28-Feb-2021)
dumpe2fs: Input/output error while trying to open myvg-debian_rimage_1
Couldn't find valid filesystem superblock.
如果我尝试修复它:lvconvert --repair myvg/debian /dev/sdc1
,它会说 /dev/sda1 上没有足够的空间。是的,sda1 上确实没有足够的空间,因此我指定 sdc1 作为参数,但 lvm 忽略了它。
当我使用实时闪存驱动器操作系统启动时,我可以看到两个丽美 dumpe2fs 中有不同的最后修改时间。
虽然我可以在实时闪存驱动器操作系统中获取此 raid1 LV 同步,但它仍然无法在正常启动中正确启动。
有人有什么想法吗?
顺便说一句,它PV /dev/sdd1 not found
有时也会报告错误,因为我删除了一个未使用的 /dev/sdc,sdd 现在为 sdc。我已经update-grub
和了update-initramfs
,但它仍然继续出现。我认为 PV 以其 UUID 区分,更改路径应该不会影响它,尽管我不明白它在哪里保存了/dev/sdd1
;我已经更新了 initramfs 和 grub.cfg。
答案1
好的,我找到原因了。在 initramfs 启动阶段,我的一个磁盘(丢失的 lv 的 pv)比另一个磁盘启动得晚。在 raid1 中,当一个磁盘准备就绪时,虚拟块设备(rootfs)变为活动状态。
一旦 rootfs 分区激活,它就会被挂载,启动继续,但 lvm raid1 分区被使用无法添加更多 pv
(我们可以用以下方式添加缺失的 pv lvchange --refresh myvg/debian
),因此 raid1 的缺失支路被标记为缺失。
要解决这个问题,只需等待 initramfs 中的所有 pv 启动即可。我们可以创建一个脚本来/etc/initramfs-tools/scripts/init-premount
等待所有 pv 启动。(有一个类似的错误
在 debian 错误系统中。)
最简单的方法就是睡一小会儿:
#!/bin/sh
sleep 30
或者检测 vg 中丢失的 pv:(将vg
变量重命名为您的 vg 名称。)
#!/bin/sh
# /etc/initramfs-tools/scripts/init-premount/vg-complete-wait
wait_interval='1 2 2 2 2 2 2 2 5 10 30 60'
vg=myvg
lvm_pv_complete() {
local vg=$1
local LVM2_VG_MISSING_PV_COUNT
eval $(lvm vgs -o vg_missing_pv_count --nameprefix --noheading $vg)
if [ "$LVM2_VG_MISSING_PV_COUNT" -eq 0 ]
then return 0
else return $LVM2_VG_MISSING_PV_COUNT
fi
}
for s in $wait_interval
do
sleep $s
lvm_pv_complete $vg && exit 0
lvm_missing_pv_count=$?
done
. /scripts/functions
panic "lvm $vg miss $lvm_missing_pv_count pv"
在我的条件下,较慢的pv通常需要大约6秒才能启动。
initramfs(针对 debian)中的所有启动阶段都记录在
initramfs 工具(7),并且可以使用启动参数探索 initramfs 或调试脚本break=premount
。请参阅initramfs-tools(7)#调试部分。
initramfs 外壳
要添加启动参数,请将其附加break=premount
到
linux vmlinuz root=UUID=xxx
grub 中的行,然后 initramfs 中的启动脚本将为您删除一个 shell,或者如果启动脚本遇到致命错误。
在 shell 中,exit
解决问题后可以使用命令继续启动。(不要使用<C-d>
,否则会终止整个启动脚本。)