nixos-specialisation-tuning

NixOS 分面设计与本地推理调优

用于两类任务：把 NixOS 配置拆成多个启动面，以及在统一内存设备上让本地大模型跑得动、跑得对、跑得快。

适用场景

• 需要"默认精简 + 可选全功能"两套配置，开机菜单选择
• 改动引导器 / 调整默认引导面后系统无法启动
• 分面热切换后服务看似"切成功了"但功能不对（无桌面、D-Bus 服务无法激活）
• 本地 llama.cpp 服务出现输出退化、加载失败、速度异常
• 需要判断某项优化是否值得（要求给出成本/收益/代价，而非单一收益）

分面架构

三文件布局

文件	职责	原则
spec/<默认面>.nix	默认配置（如 headless core）	只 import 必需模块
spec/<可选面>.nix	specialisation.<name>.configuration	叠加在默认面之上
system/base.nix	两面共用的模式无关底座	不含只服务某一面的配置

# flake.nix
nixosConfigurations.HOST.modules = [
  ./spec/core.nix                       # 默认面
  { specialisation.plasma.configuration = {
      imports = [ ./spec/plasma.nix ];  # 可选面
    };
  }
];

覆盖与冲突

共用模块中的值用 lib.mkDefault 声明，供分面用普通赋值覆盖：

# base/core 中
networking.wireless.iwd.enable = lib.mkDefault true;

# plasma 中覆盖
networking.wireless.iwd.enable = lib.mkForce true;

陷阱：lib.mkForce 覆盖整个属性时，会连带删掉其它模块对该属性的贡献。

⚠️ 实战案例：core 曾用 lib.mkForce 覆盖 environment.systemPackages，把 base 层提供的 bash 与 systemd 一并删除，导致无法登录、systemctl/reboot 全部缺失。 规则：systemPackages 类列表用追加，不用 mkForce 覆盖。

面向消费者的归属原则

一个配置项应放在它的消费者所在模块，而非"共用的那个文件"。

⚠️ 实战案例：为给 mihomo 腾出 53 端口而设置的 DNSStubListener=no，起初写进了共用的 base.nix。这会让不使用 mihomo 的面也无谓地失去 DNS stub。 判据：若某个面不启用该消费者，它就不该承受这个副作用。

引导菜单与默认面

分面意味着同一个系统有多个可引导入口，故引导器的配置也属于分面设计的一部分。

不要用命令式手段改写引导器生成的文件

规则：引导器配置必须通过其 Nix 选项声明，不得用 sed/cp 等命令式手段在 install 钩子里改写生成物。

⚠️ 实战事故（本机实际发生，导致系统无法启动）

需求：上游 nixpkgs 把 Limine 默认项硬编码为"有 specialisation 就选第 3 项" （limine-install.py:533），故只要存在可选面，默认就进可选面而非默认面。 为改回默认面，用了 extraInstallCommands 在 install 之后 sed 改写 limine.conf 的 default_entry。

失败机制——钩子执行在哈希固化之后：

limine-install.py:660  enrollConfig=true
  → b2sum = blake2b(config_file.strip())       # 对配置内容算哈希
  → limine enroll-config <BOOTX64.EFI> <hash>  # 固化进 EFI 二进制

limine.nix:471         ${install} "$@"           ← 哈希固化在此完成
limine.nix:472         ${cfg.extraInstallCommands} ← sed 在此改写配置

改写发生在固化之后 → 哈希不匹配 → Secure Boot 下引导器拒绝加载配置 → 系统无法启动。现场只能靠外部镜像手动关闭 secure boot 与 panicOnChecksumMismatch 才进入系统。