我的个人服务器（odroid-c1 微型 ARM 计算机）在 USB 磁盘上的 LVM 文件系统上运行 Archlinux。包含数据（备份等）的逻辑卷已镜像，一切运行正常。
现在，我使用以下命令镜像根文件系统：
sudo lvconvert -m 1 VG01/NASSYS
命令处理正常，一段时间后，NASSSYS LV 已 100% 镜像。
但是，重新启动后，系统会挂起，就好像无法识别镜像 LVM 卷一样。如果我恢复到非镜像 NASSYS LV，启动又可以了。
根文件系统不能简单地镜像吗？
（以下是我之前帖子的副本，已关闭且未回复，以了解完整详细信息）
上一篇文章
我已经在 Odroid-C1 计算机（一个微型计算机板，类似于 Raspberry Pi）上安装了运行 ARM Archlinux 的个人文件服务器，以及一个 Xystec PX2590 USB 盒，其中包含 4 个磁盘，其中 2 个是配置在单个 VG（VG01）中的 LVM2，还有几个未镜像的 LV，包括 NASSYS、SDATA 和 GDATA。
除了驻留在 SDCard 上的 /boot 目录（启动 Odroid-C1 所必需的）之外，Archlinux 系统安装在 NASSYS LV 上。
/boot/boot.ini 文件中描述的引导过程配置允许在从 SDCard 加载内核后将根设备更改为 NASSYS LV（请参阅下面的 setenv 语句）。
/boot/boot.ini 文件摘录
...
setenv bootargs "console=ttyS0,115200n8 console=tty0 rootwait root=/dev/mapper/VG01-NASSYS lvmwait=/dev/mapper/VG01-NASSYS rw no_console_suspend vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout_mode} ${disableuhs} ${hdmi_hpd} ${hdmi_cec}"
ext4load mmc 0:1 0x21000000 /boot/uImage
ext4load mmc 0:1 0x30000000 /boot/uInitrd
ext4load mmc 0:1 0x21800000 /boot/dtbs/meson8b_odroidc.dtb
fdt addr 21800000
if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi
if test "${hdmioutput}" = "0"; then fdt rm /mesonfb; fi
bootm 0x21000000 0x30000000 0x21800000
这个配置是好的，系统启动并完美运行（请参阅我的邮政在 Odroid 论坛上阅读此安装的整个故事！）。
然后，我计划通过使用以下命令镜像我的 xDATA LV 来保护我的系统：
$ sudo lvconvert -m 1 VG01/SDATA
$ sudo lvconvert -m 1 VG01/GDATA
所有命令均正确执行，并且在镜像同步后，我重新启动了系统，系统已正常运行。
最近，我决定使用相同的命令镜像 NASSYS LV，其中包含根文件系统：
$ sudo lvconvert -m 1 VG01/NASSYS
这个命令也运行没有任何错误，镜像结束后，我重新启动了系统，但它挂起了，我不得不关闭计算机（我尝试了几次）。
然后，我使用 Minicom 使用串行控制台查看笔记本电脑上的启动过程，但看不到任何相关错误。启动过程只是停止了，似乎在等待根文件系统......所以我怀疑NASSYS的镜像在某种程度上打破了这种认识
通过使用以下命令将 NASSYS 从我的笔记本电脑恢复到线性 LV 来确认这一点：
$ sudo lvconvert -m 0 VG01/NASSYS
Odroid-C1 再次正常启动。
这是启动失败时启动过程的最后几行
...
[ 6.549908@0] sda: sda1
[ 6.564824@0] sd 0:0:0:0: [sda] No Caching mode page found
[ 6.567473@0] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 6.576850@0] sd 0:0:0:0: [sda] Attached SCSI disk
[ 7.189162@3] device-mapper: uevent: version 1.0.3
[ 7.192823@3] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: [email protected]
[ 7.228105@2] bio: create slab <bio-2> at 2
[ 8.639100@0] emmc: mmc_rescan_try_freq: trying to init card at 300000 Hz
[ 8.678075@0] aml_emmc_hw_reset 1379
<<< BOOT HANGED HERE >>>
以及成功时启动过程的相同部分
....
[ 6.268597@3] sd 0:0:0:3: [sdd] No Caching mode page found
[ 6.268602@3] sd 0:0:0:3: [sdd] Assuming drive cache: write through
[ 6.268609@3] sd 0:0:0:3: [sdd] Attached SCSI disk
[ 6.332835@2] sd 0:0:0:2: [sdc] No Caching mode page found
[ 6.335515@2] sd 0:0:0:2: [sdc] Assuming drive cache: write through
[ 6.341668@2] sd 0:0:0:2: [sdc] Attached SCSI disk
[ 6.938489@1] device-mapper: uevent: version 1.0.3
[ 6.941347@1] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: [email protected]
[ 6.991678@0] bio: create slab <bio-2> at 2
[ 7.504299@1] force enable DISCARD here for ext4 fs
[ 7.514669@1] checked enable EXT4 DISCARD here
[ 7.517501@1] EXT4-fs (dm-2): mounting with "discard" option, but the device does not support discard
[ 7.525519@1] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null)
[ 8.539137@0] emmc: mmc_rescan_try_freq: trying to init card at 300000 Hz
[ 8.552060@3] systemd-journald[111]: Received SIGTERM from PID 1 (systemd).
[ 8.578083@0] aml_emmc_hw_reset 1379
[ 9.148086@1] Changing uart_ao_ttyS0: baud from 0 to 115200
[ 10.227180@2] EXT4-fs (dm-2): re-mounted. Opts: data=ordered
[ 10.284815@2] systemd-journald[245]: Failed to set file attributes: Inappropriate ioctl for device
[ 11.498794@3] Driver for 1-wire Dallas network protocol.
[ 12.149753@3] ionvideo open
[ 12.152921@3] ionvideo_stop_generating!!!!
[ 12.155830@3] ionvideo release
[ 12.149860@3] amlvideo openamlvideo close[ 13.336840@3] systemd-journald[245]: Received request to flush 1
[ 13.402213@0] force enable DISCARD here for ext4 fs
[ 13.411071@0] checked enable EXT4 DISCARD here
[ 13.414142@0] EXT4-fs (mmcblk0p1): mounting with "discard" option, but the device does not support discard
<<< BOOT CONTINUES NORMALLY >>>
...
尽管在互联网上进行了很多搜索，但我找不到任何有关LVM此类问题的信息。它可能是ARM特有的吗？
或者我错过了下面 LVM 配置文件中的任何内容吗？
config {
checks = 1
abort_on_errors = 0
profile_dir = "/etc/lvm/profile"
}
devices {
dir = "/dev"
scan = [ "/dev" ]
external_device_info_source = "none"
obtain_device_list_from_udev = 1
cache_dir = "/etc/lvm/cache"
cache_file_prefix = ""
write_cache_state = 1
sysfs_scan = 1
multipath_component_detection = 1
md_component_detection = 1
fw_raid_component_detection = 0
md_chunk_alignment = 1
data_alignment_detection = 1
data_alignment = 0
data_alignment_offset_detection = 1
ignore_suspended_devices = 0
ignore_lvm_mirrors = 1
disable_after_error_count = 0
require_restorefile_with_uuid = 1
pv_min_size = 2048
issue_discards = 0
}
allocation {
maximise_cling = 1
use_blkid_wiping = 1
wipe_signatures_when_zeroing_new_lvs = 1
mirror_logs_require_separate_pvs = 0
cache_pool_metadata_require_separate_pvs = 0
thin_pool_metadata_require_separate_pvs = 0
}
log {
verbose = 0
silent = 0
syslog = 1
overwrite = 0
level = 0
indent = 1
command_names = 0
prefix = " "
debug_classes = [ "memory", "devices", "activation", "allocation",
"lvmetad", "metadata", "cache", "locking" ]
}
backup {
backup = 1
backup_dir = "/etc/lvm/backup"
archive = 1
archive_dir = "/etc/lvm/archive"
retain_min = 10
retain_days = 30
}
shell {
history_size = 100
}
global {
umask = 077
test = 0
units = "h"
si_unit_consistency = 1
suffix = 1
activation = 1
proc = "/proc"
locking_type = 1
wait_for_locks = 1
fallback_to_clustered_locking = 1
fallback_to_local_locking = 1
locking_dir = "/run/lock/lvm"
prioritise_write_locks = 1
abort_on_internal_errors = 0
detect_internal_vg_cache_corruption = 0
metadata_read_only = 0
mirror_segtype_default = "raid1"
raid10_segtype_default = "raid10"
sparse_segtype_default = "thin"
use_lvmetad = 1
}
activation {
checks = 0
udev_sync = 1
udev_rules = 1
verify_udev_operations = 0
retry_deactivation = 1
missing_stripe_filler = "error"
use_linear_target = 1
reserved_stack = 64
reserved_memory = 8192
process_priority = -18
raid_region_size = 512
readahead = "auto"
raid_fault_policy = "warn"
mirror_log_fault_policy = "allocate"
mirror_image_fault_policy = "remove"
snapshot_autoextend_threshold = 100
snapshot_autoextend_percent = 20
thin_pool_autoextend_threshold = 100
thin_pool_autoextend_percent = 20
use_mlockall = 0
monitoring = 1
polling_interval = 15
activation_mode = "degraded"
}
dmeventd {
mirror_library = "libdevmapper-event-lvm2mirror.so"
snapshot_library = "libdevmapper-event-lvm2snapshot.so"
thin_library = "libdevmapper-event-lvm2thin.so"
}
感谢您的帮助。
答案1
我自己回答。 Odroid-C1 的 Archlinux 内核不包含 dm_raid 模块，该模块是访问 LVM 镜像所必需的（现在默认为 raid1）。
解决方案是将其包含在 /etc/mkinitcpio.conf 文件的 MODULES 变量中并重新生成 uInitrd。
问题解决了。
答案2
旧链接似乎不起作用，因此这里没有足够的详细信息。它在启动过程中的哪个点挂起，卡住之前的最后几条消息是什么？你有单独的/boot分区吗？
答案3
我在 2020 年遇到了类似的问题，当时我正在将系统升级到 Ubuntu 18.04，并希望为我的根 ( /) 和/home分区设置 RAID1。只是，不知何故，它根本无法启动。
以下命令不会执行与之前相同的操作：
$ sudo lvconvert -m 1 VG01/NASSYS
在过去，这将使用以下等效项：
$ sudo lvconvert -m 1 --type mirror VG01/NASSYS
但在较新的系统上，它会这样做：
$ sudo lvconvert -m 1 --type raid1 VG01/NASSYS
问题是我的旧系统不希望从 RAID1 分区启动。它从分区启动得很好mirror。
因此dm_raid模块按预期安装，但由于某种原因它无法识别raid1我的 LVM 分区的模式。据我了解，这是因为我安装了旧版本，并且该计算机上的 LVM 设置有点不对劲，并且 GRUB 加载程序以某种方式失败。我必须清除这些驱动器上的所有内容才能开始清理以使其正常工作（我想，我没有尝试，因为我目前没有备用驱动器可供测试）。
因此，如果您在 2020 年以后遇到此类问题，那可能是因为您安装的是旧版本。如果您有可能清除驱动器并重新开始，我建议您这样做，而不是乱搞后备（特别是因为“镜像”选项被标记为已弃用）。