Alpine容器未运行udev且udev_sync/udev_rules为1，lvcreate为何成功？

我正在开发一款LVM CSI，可在容器内创建逻辑卷（LVM）。在Alpine基础镜像中执行lvcreate命令可成功创建，但在CentOS、Ubuntu等其他基础镜像中执行则失败。已按需求将宿主机路径/dev挂载至容器，且容器已设置为privileged模式。

错误信息如下：

# lvcreate -y -L 4M lvmvg  -n test4
/dev/lvmvg/test4: not found: device not cleared
Aborting. Failed to wipe start of new LV

为排查问题，我为lvcreate命令添加了-vvv参数，详细日志显示容器内未运行udev。据此我找到两种在CentOS基础镜像中创建LV的方法：

• 在容器内运行udev命令后即可创建LV；
• 修改容器内/etc/lvm/lvm.conf文件，将udev_sync和udev_rules设为0后即可创建LV。

但我不确定这两种方法是否存在潜在风险。

我的核心疑问：Alpine容器内未运行udev，且udev_sync与udev_rules也设置为1，为何lvcreate命令仍能成功执行？

为什么Alpine下lvcreate能成功？ #

Alpine用的是busybox自带的轻量级设备管理工具mdev，和CentOS/Ubuntu的systemd-udev不是同一套实现。mdev默认会在容器启动时通过/etc/init.d/mdev自动初始化，扫描/dev目录并生成必要的设备节点，包括LVM创建的逻辑卷节点。

另外，Alpine打包的lvm2工具做了容器环境适配：当检测到没有完整systemd环境时，即便udev_sync=1，也不会强制等待udev完成设备节点创建，而是直接跳过检查继续执行逻辑卷创建流程。

两种解决方法的潜在风险 #

1. 容器内运行udev

   • 风险点：宿主机和容器的udev规则可能冲突，容器内的udev操作可能意外修改宿主机的设备节点权限或属性；容器重启后需要重新启动udev，增加部署复杂度；部分环境下容器内启动udev可能引发资源泄漏或设备节点混乱。
   • 适用场景：临时调试或对环境一致性要求不高的场景。

2. 修改lvm.conf关闭udev_sync和udev_rules

   • 风险点：关闭udev同步后，LVM创建的逻辑卷不会自动生成/dev/mapper或/dev/<vg>/<lv>节点，需要手动执行dmsetup mknodes创建；如果容器内有依赖udev的工具（如监控、存储管理类工具），可能出现设备无法识别的问题。
   • 适用场景：容器化LCSI的生产环境，能避免udev带来的冲突，同时可通过CSI逻辑手动处理设备节点创建。

内容的提问来源于stack exchange，提问作者styshoo