在 x86 宿主机上构建 ARM64 Ubuntu 24.04 rootfs 时遇到Failed to take /etc/passwd lock: Invalid argument的完整解决记录一、问题现象环境宿主机VMware Ubuntu 20.04x86_64内核 6.6构建方式通过debootstrapqemu-user-static在 chroot 环境中构建 ARM64 架构的 Ubuntu 24.04 (Noble) rootfs错误信息bashSetting up systemd (255.4-1ubuntu8) ... Failed to take /etc/passwd lock: Invalid argument dpkg: error processing package systemd (--configure): installed systemd package post-installation script subprocess returned error exit status 1该问题发生在debootstrap --second-stage阶段systemd 包的 postinst 脚本执行时触发。systemd 包配置失败后整个构建过程卡死无法继续安装其他包。二、根本原因分析2.1 systemd v254 移除了 OFD 锁的 fallback 机制在 systemd v253 及更早版本中文件锁的实现逻辑是先尝试 Linux 特有的fcntl(F_OFD_SETLKW)OFD 锁如果失败返回EINVAL则回退到传统的 POSIXflock(F_SETLKW)。从systemd v254 开始这个 fallback 被彻底移除commited70a34ec0。systemd 现在硬性要求底层环境必须支持F_OFD_SETLKW。受影响的版本包括 Ubuntu 24.04 自带的 systemd 255.4-1ubuntu8.1。关键时间点该问题于2024年6月5日systemd 版本255.4-1ubuntu8.1发布后开始被大规模报告。2.2 qemu-user-static 不支持 OFD 锁QEMU 的用户态模拟linux-user不支持 Open File Description (OFD) 锁。在linux-user/syscall.c中target_to_host_fcntl_cmd函数没有处理F_OFD_SETLK/F_OFD_SETLKW/F_OFD_GETLK的 case 分支任何调用都直接返回EINVAL。QEMU Bug #1893010于 2020 年 8 月报告有人在 2020 年提交了补丁qemu-5.0.0-ofd-fcntl.patch但至今未被合并到 QEMU 主线状态仍为New。2.3 报错调用链textsystemd.postinst ↓ pwconv (shadow-utils 包) ↓ libshadow.so → pw_lock() ↓ fcntl(F_OFD_SETLKW) → qemu-user-static 不支持 → 返回 EINVAL注意这是一个常见的认知误区。很多网上教程说替换/bin/systemd-sysusers为echo可解决但这个方案只适用于 WSL1 环境报错来自systemd-sysusers本身。在qemu-user-static chroot 场景下报错来自pwconv→libshadow.so替换systemd-sysusers完全无效。三、尝试过的无效方案踩坑记录3.1 替换/bin/systemd-sysusers为echo操作bashcd /bin mv -f systemd-sysusers systemd-sysusers.org ln -s echo systemd-sysusers结果无效。报错来自pwconv不是systemd-sysusers。该方案只适用于 WSL1 环境下systemd-sysusers自身报错的场景。3.2 修改 postinst 脚本在systemd-sysusers后添加|| true操作bashfind /var/lib/dpkg/info -name *.postinst -exec sed -i s/systemd-sysusers/systemd-sysusers || true/g {} \;结果无效。systemd.postinst中pwconv在systemd-sysusers之前执行脚本在pwconv行就报错退出了根本跑不到systemd-sysusers。3.3 预创建 systemd 所需用户和组操作在--customize-hook中手动写入/etc/group、/etc/passwd、/etc/shadow。结果无效。报错来自pwconv→libshadow.so→pw_lock()→fcntl(F_OFD_SETLKW)预创建用户绕不过这个锁调用。3.4 升级宿主机 QEMU 到 8.0.x分场景有效Ask Ubuntu 上有用户报告通过 backports 升级 QEMU 到 8.0.x 解决了问题。但该方案有以下限制适用场景宿主机直接 chroot 构建文件系统为普通 ext4/btrfs 等宿主机 Ubuntu 20.04 通过 backports 升级到 8.0.x不适用场景Docker overlay2 存储驱动环境下即使升级到 8.0.xQEMU 官方 OFD 锁补丁2020 年提交从未被合并到主线因此升级版本不一定保证解决操作命令bashsudo add-apt-repository ppa:canonical-server/server-backports sudo apt-get update sudo apt-get upgrade qemu-user-static3.5 使用multiarch/qemu-user-static --reset -p yes操作bashdocker run --rm --privileged multiarch/qemu-user-static --reset -p yes结果无效。该命令只修复 binfmt 注册解决找不到 arm64 解释器的问题不修复 QEMU TCG 中struct flock跨架构 ABI 转换的缺陷。该方案仅在 Docker 环境下被尝试属于坑点之一。3.6 使用ischroot技巧操作在--essential-hook中将/usr/bin/ischroot链接到/bin/false。结果无效。systemd.postinst没有用ischroot保护pwconv调用ischroot返回什么都无法阻止pwconv执行。四、最终可行的方案4.1 方案一升级宿主机的 QEMU在宿主机 Ubuntu 20.04 上通过 backports 将 QEMU 升级到 8.0.x 版本可能解决该问题。此方案仅在宿主机直接 chroot 构建非 Docker 环境且文件系统为普通 ext4/btrfs非 overlay2时可能有效。在 Docker overlay2 环境下该方案无效。4.1.1 方法一通过 backports PPA 升级bashsudo add-apt-repository ppa:canonical-server/server-backports sudo apt-get update sudo apt-get upgrade qemu-user-static4.1.2 方法二手动安装 8.0.4 定制版 deb 包定制版qemu-user-static与binfmt-support包存在冲突。binfmt-support提供 SysVinit 启动脚本/etc/init.d/binfmt-support而定制版提供 systemd 服务单元/lib/systemd/system/systemd-binfmt.service两者执行顺序会导致 systemd 设置被覆盖。因此需要先移除binfmt-support再安装定制版。bash# 1. 移除冲突的 binfmt-support sudo apt-get purge binfmt-support -y # 2. 下载 8.0.4 定制版 deb 包 wget https://archive.spacemit.com/qemu/qemu-user-static_8.0.4%2Bdfsg-1ubuntu3.23.10.1_amd64.deb # 3. 安装 deb 包 sudo dpkg -i qemu-user-static_8.0.4dfsg-1ubuntu3.23.10.1_amd64.deb # 4. 重启 systemd-binfmt 服务将 qemu-user-static 注册到内核 sudo systemctl restart systemd-binfmt.service4.1.3 验证安装bashqemu-aarch64-static --version # 应显示类似 8.0.4 的版本号注意QEMU 官方 OFD 锁补丁2020 年提交从未被合并到 QEMU 主线因此升级到 8.0.x 并不保证在所有环境下都能解决该问题。本次移植过程就是通过这个解决的升级宿主机的 QEMU4.2 方案二替换pwconvchroot qemu-user-static 场景在debootstrap --second-stage执行之前在宿主机上直接替换 chroot 内的/usr/sbin/pwconvbashROOTFS$HOME/ubuntu_rootfs # 备份原 pwconv sudo mv $ROOTFS/usr/sbin/pwconv $ROOTFS/usr/sbin/pwconv.real # 替换为空操作脚本 sudo bash -c printf #!/bin/sh\nexit 0\n $ROOTFS/usr/sbin/pwconv sudo chmod x $ROOTFS/usr/sbin/pwconv # 然后执行 debootstrap --second-stage sudo chroot $ROOTFS /debootstrap/debootstrap --second-stage原理pwconv被替换为空操作后systemd.postinst调用pwconv时直接返回成功不会触发F_OFD_SETLKW锁。代价pwconv永久返回 0/etc/shadow和/etc/passwd不同步。需要在目标系统首次启动后执行一次真实的pwconv。4.3 方案三修改 systemd 源码Launchpad Bug #2069555 中明确指出The only real fix for this issue is a modified systemd package which changes the locking mechanism.具体修改位置src/basic/lock-util.c中fcntl_lock()和fcntl_unlockpp()调用的ofd参数从true改为false。或者增加检测逻辑检测到F_OFD_SETLKW不支持时自动回退到F_SETLKW。这个方案需要自行修改源码并重新编译 systemd 包操作复杂但能根本解决问题。4.4 方案四改用完整虚拟机qemu-system-aarch64放弃qemu-user-static改用qemu-system-aarch64完整系统模拟。虚拟机内部运行完整的 ARM64 内核原生支持F_OFD_SETLKW不存在模拟缺陷。这是最可靠但速度最慢的方案。五、官方 Bug 追踪链接来源链接状态Ubuntu LaunchpadBug #2069555ConfirmedQEMUBug #1893010NewDebianBug #1126304fixed‑upstreamsystemd GitHubIssue #29512公开讨论Microsoft/WSLIssue #10397公开讨论GitHub WorkaroundInfoXMax/linux‑apt‑fix‑broken‑issue社区方案核心结论该问题的根源是 systemd v254 硬性要求 F_OFD_SETLKW而 qemu-user-static 不支持该锁。systemd 和 QEMU 两边都未修复此问题只能通过 workaround 绕过。升级 QEMU 在 Docker overlay2 环境下无效在宿主机直接 chroot 环境下可能有效但需验证文件系统类型。---------------------------------------------------------------------------------------- 后续补充内容优先同步至 GitHub如有疏漏欢迎指正。全部相关技术笔记托管于 GitHub 仓库欢迎访问。 GitHub仓库kyshipit/tech‑notes------------------------------------------------------------------------------------------