在嵌入式系统、物联网设备和快速部署的云镜像场景中,镜像体积、部署灵活性和可维护性是最常被关注的问题。NixOS 以其可复现、声明式配置和构建隔离的特性,天然适合构建可控的系统镜像。但要把 NixOS 打造成既轻量又能在未知磁盘容量上自动扩展的 appliance,需要借助 systemd-repart 来在首次启动时动态创建或调整磁盘分区。本文围绕如何构建"自增长"的 NixOS 镜像展开,分享配置示例、运行流程、调试方法以及常见坑与优化建议,让你能在真实设备或虚拟机中稳定复现该方案。NixOS 的优势、需求与策略NixOS 的核心优势在于声明式管理系统配置与包的可复现性。对 appliance 场景的需求是镜像尽可能小、运行时不带 Nix 包管理器本身、并且能在首次引导时把剩余的磁盘空间自动分配给数据分区如 /home 与 /var。
这样的设计带来两个好处。首先,镜像更小,网络传输与写盘速度更快;其次,制造与部署流程统一,单一镜像可以适配不同大小的目标存储设备。实现这些目标需要在镜像构建阶段把系统只包含必要的运行时文件,同时把系统核心放入一个只读的 squashfs 分区以减少镜像体积。启动时将根文件系统运行在 tmpfs 中,并通过系统配置在内存中动态生成 /etc。剩余磁盘空间通过 systemd-repart 在 initrd 阶段被划分并格式化为持久分区,从而实现"自增长"能力。systemd-repart 的双重角色与工作流systemd-repart 在本方案中承担两个角色。
其一,image.repart 模块在镜像构建时定义分区的初始内容,例如 ESP(EFI System Partition)中的 bootloader、以及包含系统闭包的 squashfs 分区,这样生成的原始镜像在被 dd 写入磁盘后即可引导。其二,systemd-repart 在引导过程的 initrd 阶段运行,检测磁盘实际分区表与我们期望的分区模板的差异,自动创建缺失的分区并按定义的权重分配剩余空间,从而填充 /home 和 /var。配置要点与示例解析要实现上述行为,通常会准备四个主要文件:configuration.nix、filesystems.nix、image.nix、inflate.nix。configuration.nix 用于汇总模块并禁用运行时的 Nix 机制以保持系统只读与轻量。filesystems.nix 指定系统启动时的挂载点,其中根文件系统可以被配置为 tmpfs,/nix/store 被挂载为 squashfs,/boot 指向 vfat 的 ESP,/home 与 /var 指向按标签分区的 ext4。将根文件系统设为 tmpfs 能确保系统以无状态方式运行,并在每次引导时根据 image-based-appliance 配置重新生成 /etc。
image.nix 是镜像构建阶段重要的定义文件,通过导入 NixOS 的 image/repart 模块,定义了分区名、分区内容以及每个分区的 repartConfig。常见的做法是在 ESP 分区中放入 EFI 可执行文件与 kernel+initramfs(或 UKI),并把系统的 toplevel derivation 写入一个 squashfs 分区,设置 Label 为 nix-store,以及 ReadOnly = yes 来保证系统文件不被篡改。inflate.nix 定义 initrd 阶段 systemd.repart 的行为,要点是启用 boot.initrd.systemd.repart.enable 并指明操作的设备(例如 /dev/sda),以及通过 systemd.repart.partitions 对需在首启创建的分区进行声明,使用 Format、Label、Type 与 Weight 等字段描述每个分区的格式与大小相对权重。Weight 字段特别有用,它允许在磁盘大小未知时根据权重比例分配剩余空间,例如将 home 权重设为 2000、var 权重设为 1000,使得 home 占用的空间大约是 var 的两倍。构建与运行流程在包含上述配置的 flake.nix 中将镜像作为一个 Nix 包产出,典型的构建命令为 nix build .#image。将结果写回真实磁盘可以使用 dd if=result/image.raw of=/dev/sdX bs=4M。
为了在虚拟机中快速验证可采用复制并扩展原始镜像文件的方式,先 cp result/image.raw demo-disk.raw,然后使用 qemu-img resize -f raw demo-disk.raw +10G 扩展镜像,在 VM 引导时 systemd-repart 将会检测多出的空间并按照 inflate.nix 的定义创建新的 ext4 分区。在首次引导后,可以通过 journalctl -u systemd-repart.service 查看它的操作记录,通常会显示创建分区、写入分区表并通知内核重新读取分区表的日志;后续引导中,systemd-repart 会检测到无变更而退出。实践中的调试技巧与注意事项构建与部署该方案时会遇到若干容易忽视的细节。首先要确保 bootloader 路径与命名准确,ESP 中的文件路径和 UKI 名称需要与 bootloader 配置一致,并且在不同 CPU 架构(如 x86_64 与 aarch64)下要注意 efiArch 的差异。其次,Label 与 Type 的配对对于 systemd-repart 的匹配机制至关重要,使用明确的 Label 名称(例如 boot、nix-store、home、var)能够减少歧义。第三,如果目标设备上已经存在旧的分区或标记,systemd-repart 可能不会覆盖这些分区,建议在制造流程中使用 dd 将镜像全面写入目标盘或在首次启动前确保盘是干净的。
第四,initrd 阶段启用 systemd-repart 能保证在根挂载前对磁盘做修改,但也要小心并发的挂载流程与依赖服务,确保 repart 服务在挂载分区前完成。第五,选择将根设为 tmpfs 时需评估内存占用与应用场景,若设备内存受限需权衡是否采用 tmpfs 或直接把根写入可擦写分区。第六,若采用 squashfs 作为 /nix/store,实现只读系统是极佳的减重策略,但也要注意 squashfs 在某些平台上的性能与压缩算法选择,使用 zstd 可以在压缩比与解压速度间取得良好平衡。安全性与更新策略在某些场景中,为了保持系统可更新性又不把 Nix 包管理器带入运行时,可以采用 A/B 不可变系统分区结合 systemd-sysupdate 或自定义更新机制。systemd-sysupdate 可以下载完整的更新镜像并在下次重启时切换到新分区,从而实现原子更新。NixOS 自带的系统切换机制依赖于运行时可用的 Nix,而在轻量 appliance 中更常见的是通过外部管理服务器提供新的镜像版本,设备周期性拉取并写入备用分区,随后通过引导选择机制切换。
备份与恢复策略也要提前规划,尤其是在远程设备上。可以在镜像中加入简单的故障恢复流程,例如在启动失败时回退到上一已知良好的分区,或保持一个最小的救援分区以便远程诊断。优化与减重建议要把镜像做得更小、更适配嵌入式场景,可以从几个方向入手。减少包闭包:通过 NixOS 的配置仅启用运行时必要的服务与库,避免在镜像中引入构建工具与开发库。使用更紧凑的 init 系统与压缩算法:对于 squashfs 推荐使用 zstd 压缩以减小镜像同时保证解压性能。精简内核与驱动:如果目标设备硬件已知,可以构建包含最小驱动集的内核或使用 kernel modules 的按需加载策略。
日志、缓存与不必要的数据目录应在构建时标记或排除,或者配置为在挂载的持久分区才保存。跨平台构建与自动化在需要支持多种 CPU 架构或大量设备时,建议把镜像构建流程放入 CI,并使用 flake 与 cross-compilation 支持来自动生成不同平台的镜像。flake.nix 可以集中管理构建参数、系统类型与导出产物,使维护更加可控。运行 demo 与常见命令验证在本地验证时可以按以下流程进行验证而无需直接触及物理硬盘。先执行 nix build .#image 生成 image.raw,然后复制并扩展 demo-disk.raw,接着使用 qemu-system-x86_64 -drive file=demo-disk.raw,format=raw 等命令引导虚拟机。引导后通过 journalctl -u systemd-repart.service、lsblk 与 parted 等工具确认分区创建与大小分配是否符合预期。
常见调试命令包括 journalctl -b 查看完整启动日志、cat /proc/cmdline 检查内核参数、blkid 获取分区标签与 UUID。结语将 NixOS 与 systemd-repart 结合,可以非常优雅地解决 appliance 镜像在大小与部署环境不可预知时的适配问题。通过在镜像中把系统核心以只读 squashfs 形式打包,并在 initrd 阶段用 systemd-repart 动态创建持久数据分区,可以实现单一镜像适配多种大小存储设备的目标。配合 A/B 更新策略或 systemd-sysupdate,还能提供稳定的远程更新与回滚能力。实践中要注意 bootloader 路径、Label/Type 的一致性、initrd 与重分区时序以及内存占用带来的影响。掌握这些细节后,就能构建出既小巧又灵活、利于大规模生产和远程维护的 NixOS appliance。
若需基于该方法为你的特定硬件或产品线定制镜像,建议先在虚拟化环境完成全套验证,再逐步迁移到真实设备,并在生产流程中加入镜像完整性校验与恢复机制,从而把自动扩展与稳定部署结合成可复制的制造流程。 。
