nixos-installer/modules/fs
2023-01-29 21:08:12 +01:00
..
boot.nix.md upgrade to 22.11, add extlinux & hetzner-vps: 2022-12-28 16:43:16 +01:00
default.nix improve installation, add support for: 2022-05-31 03:41:28 +02:00
disks.nix.md fix gptfdisk, integrate some bash aliases 2023-01-03 18:50:07 +01:00
keystore.nix.md add VPS-worker factory, add vm-exec module, improve run-qemu function, add push-flake script, support installing systems as non-root, script refactoring 2023-01-29 21:08:12 +01:00
README.md add hardware config for Raspberry PIs, start making scripts more robust, improve compatibility with containers 2022-11-30 13:41:21 +01:00
temproot.nix.md add VPS-worker factory, add vm-exec module, improve run-qemu function, add push-flake script, support installing systems as non-root, script refactoring 2023-01-29 21:08:12 +01:00
zfs.nix.md add VPS-worker factory, add vm-exec module, improve run-qemu function, add push-flake script, support installing systems as non-root, script refactoring 2023-01-29 21:08:12 +01:00

Automated File System Setup

NixOS usually gets set up by booting a live system (e.g. from USB), manually setting up file systems on the target disks, mounting them and then using nixos-generate-config to deduct the fileSystems from the mounted state.

This runs completely contrary to how NixOS usually does (and should) work (the system state should be derived from the config, not the config from the system state), and it does not at all work for hermetic flakes (where all config needs to be committed in the flake repo) or for automated installations.

disks, keystore, and zfs allow to not only specify how file systems are to be mounted, but also which devices, partitions, and LUKS layers they live on, and for ZFS the complete pool and dataset layout. The bash functions in lib/setup-scripts take these definitions and perform arbitrarily complex partitioning and file systems creation, as long as:

  • Actual device instances or image files (by path) are passed to the installer for each device specified in the configuration.
  • Disks are partitioned with GPT, but may optionally have an MBR for boot partitions if the loader requires that.
  • fileSystems.*.device/boot.initrd.luks.devices.*.device/wip.fs.zfs.pools.*.vdevArgs refer to partitions by GPT partition label (/dev/disk/by-partlabel/*) or (LUKS) mapped name (dev/mapper/*).
  • boot.initrd.luks.devices.${name} have a wip.fs.keystore.keys."luks/${name}/0" key specified.

boot and temproot help with a concise (if somewhat opinionated) file system setup that places / on a file system that gets cleared during reboot, to achieve a system that is truly stateless (or at least explicitly acknowledges where it has state).