archinstall QEMU 测试助手详解：用 mkosi UKI 与 qcow2 硬盘在虚拟机中验证 Arch 安装

运维CLI【免费下载链接】archinstallArch Linux installer - guided, templates etc.项目地址https://gitcode.com/gh_mirrors/ar/archinstall点击查看免费下载archinstall 仓库内置了一套「构建即可启动」的测试工具链QEMU 助手脚本 负责在本地 KVM 虚拟机中拉起由 mkosi 构建的 UKI 引导镜像并挂载若干 qcow2 硬盘供你在其中运行 archinstall 完成一次真实安装安装完成关机后再以“纯硬盘”模式重启同一组磁盘即可在 EFI 环境下验证安装产物能否独立引导。读完后你将掌握这套两阶段验证流程的完整命令、脚本的全部 CLI 参数与默认值以及 OVMF 持久变量、virtio-scsi 块设备等底层实现细节。两阶段验证工作流test_tooling/qemu/README.md 描述的用法分为四步第 1 步构建 UKI 镜像。该脚本必须与 mkosi 测试工具链 配合使用。先执行构建命令对应 mkosi 配置mkosi -B build第 2 步带 UKI 和硬盘启动虚拟机。按 README 给出的命令同时传入构建产物image_13.efi和一个或多个路径:容量形式的硬盘python test_tooling/qemu/qemu.py \ --uki ./test_tooling/mkosi/mkosi.output/image_13.efi \ --harddrive ~/test.qcow2:15G \ --harddrive ~/test_large.qcow2:25G第 3 步在虚拟机内运行 archinstall。此时虚拟机里运行的是一个预装了 archinstall 依赖的最小 Arch 环境构建细节见下文“与 mkosi 工具链的配合”你在其中像往常一样执行 archinstall 完成分区、引导与软件包安装完成后关机。第 4 步纯硬盘模式重启验证安装。去掉--uki参数只保留相同的硬盘列表再次运行python test_tooling/qemu/qemu.py \ --harddrive ~/test.qcow2:15G \ --harddrive ~/test_large.qcow2:25GREADME 指出这样会“以 EFI 模式仅挂载硬盘启动以验证安装”。由于硬盘路径完全一致脚本会为这次运行沿用同一份 OVMF NVRAM 变量文件机制见下文因此安装期间写入 UEFI 引导条目的结果会被带入这次验证启动——这正是该设计能够闭环的关键。qemu.py 的完整参数说明脚本基于argparse定义了四个参数组。以下默认值均来自 qemu.py 的参数定义。引导源互斥组参数作用--uki以-kernel方式引导一个 UKI统一内核镜像即 mkosi 产物image_13.efi--kernel声明引导一个 Linux 内核参数组名为 Kernel配套--initrd--iso以只读 CD-ROM 设备挂载 ISO 9660 镜像三者与--harddrive至少提供一个否则脚本抛出ArgumentError: Cannot boot this machineqemu.py#L94-L95。硬件参数参数默认值说明--bios关store_true关闭 EFIedk2/ovmf改用 BIOS 引导与--uki互斥组合使用会直接报错--memory8192MB注入虚拟机的内存量最终拼为-m--harddrive无可重复每声明一次就挂载一块 virtio-scsi 硬盘格式为test.qcow2:15G冒号后是容量--cpuos.cpu_count() - 1分配核心数拼为-smp N,sockets1,dies1,coresN,threads1--resolution1920x1107VGA 分辨率解析后拼为-device VGA,edidon,xres...,yres...--initrd无属于 Kernel 参数组从源码看当前 qemu 命令行拼装中只有--uki会被写入-kernel--kernel/--initrd尚未接入实际命令--initrd的帮助文案“Defines which ISO to run”也明显是过时描述使用时以--uki为主网络参数参数组说明明确写道这些选项用于“禁用 Qemu 默认的-net nic -net user网络行为”。参数默认值说明--tap无创建/使用一个 TAP 接口并以virtio-net-pci传给虚拟机--tap-mac52:54:00:00:00:02TAP 网卡的 MAC 地址--bridge无创建网桥并把--tap挂入--bridge-mac无若给出--bridge未指定 MAC 则回退为52:54:00:00:00:1网桥 MAC--bridge-master无将哪个物理接口设为网桥的 master必须先有--bridge参数校验逻辑qemu.py#L91-L113包括--bridge-master/--bridge-mac不能脱离--bridge使用--tap的接口若无 master 会打印橙色警告允许“无网络但存在网卡”的测试场景只给--bridge*而不给--tap时警告这些参数将被忽略。从源码结构看脚本只在指定--tap时才向 qemu 追加网络设备未指定时客机内实际上没有网卡。QEMU 命令行的拼装逻辑脚本的核心是一段字符串拼接最终生成一条qemu-system-x86_64命令并打印灰色后同步执行。基础部分是qemu.py#L446-L457qemu-system-x86_64 -cpu host -enable-kvm -machine q35,accelkvm -object rng-random,filename/dev/urandom,idrng0 -device virtio-rng-pci,rngrng0 -global drivercfi.pflash01,propertysecure,valueon -smp {cpu},sockets1,dies1,cores{cpu},threads1 -device VGA,edidon,xres1920,yres1107 -device intel-iommu,device-iotlbon,caching-modeon -m {memory}要点q35 机型 KVM 加速、透传宿主机 CPU 模型、注入熵设备、启用 Intel IOMMU 模拟。OVMF pflash 与“按硬盘集合哈希”的 NVRAM非 BIOS 模式下脚本从宿主机/usr/share/ovmf/x64/复制两份文件到当前目录并追加一个哈希后缀qemu.py#L438-L443disk_paths_hash hashlib.sha1((.join(sorted([str(x) for x in harddrives.keys()]))).encode()).hexdigest() shutil.copy2(/usr/share/ovmf/x64/OVMF_CODE.secboot.4m.fd, f./OVMF_CODE.secboot.4m.fd.{disk_paths_hash}) shutil.copy2(/usr/share/ovmf/x64/OVMF_VARS.4m.fd, f./OVMF_VARS.4m.fd.{disk_paths_hash})随后以两个 pflash 设备挂载代码只读、变量可写-drive ifpflash,formatraw,readonlyon,file./OVMF_CODE.secboot.4m.fd.{hash} -drive ifpflash,formatraw,file./OVMF_VARS.4m.fd.{hash}hash是所有硬盘绝对路径排序拼接后的 SHA-1。从源码结构看这套机制的意图是同一组硬盘README 示例中两阶段使用完全相同的路径列表会命中同一份OVMF_VARS文件——第一次运行安装阶段写入 NVRAM 的 UEFI 引导条目得以保留第二次“纯硬盘”重启即可直接依赖安装程序建立的引导链。硬盘集合一旦变化则回到一份全新的初始 NVRAM。硬盘挂载virtio-scsi 双 blockdev每块--harddrive会生成一组设备qemu.py#L464-L473-device virtio-scsi-pci,buspcie.0,idscsiN,addr0x{N8} -device scsi-hd,drivelibvirt-N-format,busscsiN.0,idscsiN-0-0-0,channel0,scsi-id0,lun0,device_iddrive-scsi0-0-0-0,bootindex{B},write-cacheon -blockdev {driver:file,filename:{hdd},aio:threads,...,discard:unmap} -blockdev {node-name:libvirt-N-format,...,driver:qcow2,file:libvirt-N-storage,backing:null}底层 file 节点用aiothreads并启用discardunmap上层 qcow2 节点启用cache.directtrue——这是典型的“接近裸盘”配置让 guest 内的 I/O 行为尽量贴近真实硬件对验证安装后的启动过程很重要。--iso则挂在下一个 SCSI 控制器上作为scsi-cdqemu.py#L474-L478。启动优先级boot_index计数器决定各设备的bootindex初始为 0若提供了--uki则 UKI 先占一位qemu.py#L461-L463之后硬盘按声明顺序依次获得递增的 bootindexISO 垫底。这正好匹配 README 的两阶段语义第一阶段 UKI 优先级最高安装环境第二阶段没有 UKI硬盘从 0 开始由 NVRAM 中的引导条目决定从哪里启动。网络设备指定--tap时追加qemu.py#L483-L485-device virtio-net-pci,mac{tap_mac},idnetwork0,netdevnetwork0.0,statuson,buspcie.0 -netdev tap,ifname{tap},idnetwork0.0,scriptno,downscriptnoscriptno,downscriptno表示 QEMU 不接管 TAP 的生命周期创建与配置全部由脚本自己在宿主机上完成。宿主机侧TAP/网桥自动配置与 sudo 交互setup_networking()qemu.py#L355-L416在启动 qemu 之前按需执行以下sudo操作并打印灰色进度提示TAP 不存在时sudo ip tuntap add dev {tap} mode tap user {username} group {groupname}网桥不存在时sudo ip link add name {bridge} type bridge指定了--bridge-macsudo ip link set dev {bridge} address {mac}指定了--bridge-master且当前 master 不符sudo ip link set dev {master} master {bridge}挂接 TAPsudo ip link set dev {tap} master {bridge}依次up网桥与 TAP 接口。这些命令的密码交互由自研的SysCommandWorker类qemu.py#L141-L343处理它用pty.fork()拉起子进程通过epoll非阻塞地读取 PTY 输出并累积到_trace_log__contains__实现了“向前搜索并推进游标”的语义于是调用方可以写成if bpassword for in handle命中后把get_sudo_password()functools.cache缓存的getpass输入写回 PTY。输出还会用正则清除 VT100 转义序列clear_vt100_escape_codes保证重放日志干净可读。这是一个小型但完整的“可编程 PTY 会话”实现值得在自动化 sudo 场景下参考。硬盘创建路径setup_disks()qemu.py#L419-L432把每个路径:容量参数解析为绝对路径并登记若文件不存在则尝试执行qemu-img create -f qcow2 {path} {size}需要注意从源码结构看该分支的 f-string 引用的是变量hdd而它在setup_disks的作用域内并未定义同名变量只出现在后面的设备拼装循环中。也就是说当磁盘文件不存在时这条自动创建路径在运行时可能抛出NameError。稳妥的实操做法是先手动预创建 qcow2 文件例如qemu-img create -f qcow2 ~/test.qcow2 15G或在 fork/修改脚本后使用其自动创建逻辑。与 mkosi 工具链的配合README 的第一句话——“Can be used with themkositest tooling”——指向 test_tooling/mkosi 目录。该工具链决定了 UKI 里装了什么mkosi.confDistributionarch、Formatuki、SecureBootfalse、Signfalse内容里含RootPasswordtoor、TimezoneEurope/Stockholm、Keymapsv-latin1、InitrdProfilesnetwork[Runtime]段配置Consolegui、CPUs4、RAM8G。版本锁定文件 mkosi.version 内容为13与 README 中产物名image_13.efi相互印证。mkosi.profiles/archinstall安装 archinstall 运行所需的软件包包括python、python-pydantic、python-textual、python-pyparted、python-uv、arch-install-scripts、dosfstools、btrfs-progs、linux等并设置KernelCommandLinequiet splash。mkosi.postinst.chroot构建期把 archinstall 仓库克隆到镜像内/root/archinstall-git并检出master分支同时用rankmirrors生成前 5 个镜像源并初始化 pacman 密钥环——这意味着虚拟机内直接python /root/archinstall-git就能跑安装。开机体验由 autologin 配置 提供 tty1 的 root 自动登录由 20-ethernet.network 让en*/eth*走 DHCP路由度量 100。mkosi 的 README 还记录了直接用mkosi qemu拉起安装环境遇到的限制需要禁用 mkosi 自动附加到-kernel的 UKI 才能正常引导安装介质作者备注“还没找到方法”——这正是独立qemu.py助手存在的动机之一也提醒读者--uki模式引导的是安装环境本身而非安装完成后的系统。适用前提与注意事项宿主机依赖需要qemu-system-x86_64、KVM 支持以及提供/usr/share/ovmf/x64/OVMF_CODE.secboot.4m.fd与OVMF_VARS.4m.fd的 OVMF 固件文件脚本按此固定路径复制网络功能额外需要 sudo 权限。BIOS 模式--bios会跳过 OVMF pflash 复制与挂载改用传统 BIOS此时不能与--uki组合脚本显式拒绝且两阶段验证依赖的 NVRAM 持久化机制也不再适用。参数覆盖面如前所述当前实现真正接入命令行的引导源是--uki与--iso/--harddrive--kernel仅参与“至少给一个引导源”的校验。同步前台执行脚本最后以subprocess.run(..., checkTrue, capture_outputTrue)运行 qemuqemu.py#L489-L494虚拟机前台运行关机后进程退出并打印输出。工作目录OVMF 文件与自动创建的逻辑都落在“当前目录”下建议在仓库根目录或一个专用目录中运行避免把OVMF_*.fd.{hash}文件散落到其他位置。小结test_tooling/qemu用不到五百行 Python 实现了一个可复用的“安装验收”环境mkosi 产出 UKI 作为安装介质qemu.py以 q35KVMvirtio-scsi 的标准配置拉起虚拟机用“硬盘路径哈希”的 OVMF 变量文件在两次运行之间保持 UEFI 引导状态从而把“装系统”和“验系统”拆成两次干净的命令。理解其中 pflash 持久化、双 blockdev 直通、PTY sudo 交互这几处实现也为在其他项目中构建类似的虚拟机测试工具提供了可直接借鉴的模式。赞分享运维CLI【免费下载链接】archinstallArch Linux installer - guided, templates etc.项目地址https://gitcode.com/gh_mirrors/ar/archinstall点击查看免费下载相关推荐archinstall 的 mkosi 测试工具链构建并验证 Arch Linux 安装介质的完整工作流archinstall 的 mkosi 测试工具链构建并验证 Arch Linux 安装介质的完整工作流 本篇围绕 archinstall 仓库中的 test运维CLIQEMU虚拟机测试快速验证build-linux系统的终极指南QEMU虚拟机测试快速验证build linux系统的终极指南 build linux是一个构建基于Linux的操作系统的开源项目它提供了自动化脚本和详细文文档教程操作系统Ventoy与虚拟机在VMware/VirtualBox中测试启动盘Ventoy与虚拟机在VMware/VirtualBox中测试启动盘 你还在为测试启动盘频繁插拔U盘、担心数据丢失而烦恼吗本文将系统介绍如何在VMware操作系统固件开发工具上一篇OpenObserve系统监控告警完整指南10个关键配置实现智能故障预警下一篇如何为tiny11builder脚本添加自定义组件移除规则完整模块化设计指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考