深度解读：如何制作更小的 NixOS ISO 镜像

背景

NixOS 以其声明式配置和可重现的构建环境著称，其中一项“酷炫”的功能是能够极其简单地基于系统配置生成虚拟机（VM）镜像。通过运行 nixos-rebuild build-vm，用户可以直接获得一个针对当前系统配置的 VM 镜像。这种机制不仅适用于完整的系统配置，甚至可以应用于任何自定义的 Nix 表达式，从而快速启动一个最小化的测试环境。

然而，这种“薄”虚拟机（Thin VM）依赖于宿主机上的 Nix 存储（/nix/store）。虽然这在本地开发中非常高效，但在某些场景下却显得力不从心。例如，当用户需要将系统部署到没有安装 Nix 的远程主机，甚至是没有 Hypervisor（虚拟化层）的传统 Linux 环境中时，这种依赖宿主机存储的 VM 格式就失效了。此时，用户需要一个标准的、自包含的 ISO 镜像，以便通过 QEMU、Libvirt 或物理光盘进行引导和运行。

尽管 NixOS 提供了生成 ISO 镜像的标准模块，但默认生成的 ISO 体积往往令人咋舌。作者通过实际构建发现，一个仅包含最基础配置（如自动登录 root 用户）的 NixOS ISO 竟然高达 458 MiB。相比之下，经典的轻量级 Linux 发行版 Damn Small Linux 仅需极小的空间即可运行完整的桌面环境，而现代 Alpine Linux 的 VM ISO 也仅为 66 MiB 左右。这种巨大的体积差异促使作者深入探究 ISO 内部的构成，并尝试通过移除不必要的依赖来显著减小镜像体积。

核心内容

1. 初始 ISO 构建与体积分析

作者首先展示了如何生成一个基础的 NixOS ISO。通过引入 iso-image.nix 模块并设置 nix.enable = false 和 documentation.enable = false 的初步尝试，ISO 体积从预期的 458 MiB 减少到了 384 MiB，但仍未达到理想状态。

为了找出体积庞大的原因，作者对生成的 ISO 文件进行了挂载和目录大小分析：

• 总体积：458 MiB。
• 主要组成部分：
  • nix-store.squashfs：416 MiB，这是包含用户空间主要文件（Nix Store）的压缩文件系统。
  • initrd：26 MiB，早期引导环境。
  • kernel (bzImage)：13 MiB，Linux 内核本身。

作者指出，内核和初始 RAM 磁盘（initrd）的体积相对固定且必要，因此优化的重点在于那 416 MiB 的 nix-store.squashfs 文件。

2. 深入剖析 Nix Store 依赖

由于 ISO 是在宿主机上构建的，nix-store.squashfs 中的内容实际上对应宿主机 /nix/store 中的包。作者通过挂载 squashfs 文件系统，并使用 nix why-depends 命令，追踪了大体积包的具体来源。

分析发现，导致体积膨胀的主要“嫌疑人”包括：

• Python 3：128 MiB
• Linux 模块：144 MiB
• Systemd：60 MiB
• Perl：56 MiB
• Glibc：34 MiB
• Boost：15 MiB

特别值得注意的是 Boost 库。通过 nix why-depends 的依赖链追踪，作者发现 Boost 是被 nix-daemon（Nix 守护进程）间接引入的。依赖链如下： nixos-system -> activate 脚本 -> etc 配置 -> nix-daemon.conf -> nix 包 -> nix-util -> boost。

这意味着，即使禁用了 Nix 服务，如果构建过程中仍然打包了 Nix 守护进程及其依赖，Boost 等库就会作为“幽灵依赖”存在于 ISO 中。

3. 瘦身尝试：禁用 Nix 与文档

为了减小体积，作者采取了以下措施：

1. 禁用 Nix 服务：设置 nix.enable = false。目的是移除 Nix 守护进程及其相关依赖（如 Boost）。
2. 禁用文档：设置 documentation.enable = false。移除手册页和 HTML 文档。

然而，初步结果显示，虽然禁用了 Nix 服务，ISO 体积仅从 458 MiB 降至 384 MiB，且 Boost 依赖依然存在。这表明仅设置 nix.enable = false 并不足以在构建阶段完全剥离 Nix 相关的构建依赖，或者有其他组件仍然间接依赖了这些库。

关键要点

• NixOS ISO 默认体积过大：一个极简配置的 NixOS ISO 默认大小约为 458 MiB，其中 416 MiB 为用户空间文件（Nix Store），远超 Alpine Linux 等轻量级发行版。
• 体积主要来源：
  • Nix Store (SquashFS)：包含所有构建依赖，是体积最大的部分。
  • 内核与 Initrd：相对固定，优化空间有限。
• 依赖追踪是关键：使用 nix why-depends 命令可以精确追踪大型包（如 Python, Boost, Systemd）的来源，从而定位冗余依赖。
• Nix Daemon 的间接依赖：即使不运行 Nix 服务，Nix 守护进程（nix-daemon）及其依赖（如 Boost）仍可能被打包进 ISO，除非在构建配置中彻底排除。
• 初步优化效果有限：仅通过 nix.enable = false 和 documentation.enable = false 只能将 ISO 从 458 MiB 减少到 384 MiB，未能彻底解决 Boost 等库的残留问题。
• 构建环境与运行环境的差异：ISO 中的内容直接映射到构建时的宿主机 /nix/store，因此构建时的依赖树直接决定了最终 ISO 的大小。

意义与影响

这篇文章不仅是一个技术教程，更揭示了 NixOS 在便携性和轻量化方面面临的挑战与机遇：

1. NixOS 的便携性悖论：NixOS 的“声明式配置”和“可重现构建”是其核心优势，但也导致了二进制依赖的膨胀。对于需要跨平台、跨环境（如无 Nix 环境）部署的场景，标准的 NixOS ISO 显得过于臃肿。
2. 精细化依赖管理的必要性：文章展示了如何利用 Nix 生态工具（如 nix why-depends）进行精细化的依赖分析。这对于希望定制最小化系统镜像的高级用户和 DevOps 工程师具有重要参考价值。
3. 推动 NixOS 轻量化发展：通过揭示默认 ISO 中存在的冗余依赖（如 Boost），作者的工作为 NixOS 社区提供了优化方向。未来，NixOS 可能会提供更完善的“最小化 ISO”构建模板，或优化默认配置以自动剥离不必要的运行时依赖。
4. 对嵌入式和边缘计算的启示：对于资源受限的边缘设备或嵌入式场景，458 MiB 的 ISO 仍然过大。通过类似的依赖剥离技术，NixOS 有望在保持其优势的同时，更好地适应轻量级部署需求。

总之，这篇博文通过一个具体的案例，深入剖析了 NixOS ISO 构建过程中的依赖问题，为追求更小、更便携系统镜像的用户提供了实用的方法和深刻的见解。