Make it easier to do unattended installations of NixOS using disko

[Jayman2000]

The goal of this pull request is to make it easier to do unattended installations of NixOS. At the moment, disko has some example code for using disko-install to do offline installations of NixOS. At the moment, if you want to use disko in order to do an unattended installation of NixOS, then your best bet is to start with that offline installer example code and to modify it so that it does unattended installations.

This pull request adds a new way of doing unattended installations. This new way of doing unattended installations has the following advantages compared to the old way:

• With the old way of doing unattended installs, you had to start with some example code and figure out how to modify it to do unattended installations. For an experienced user, doing that would probably not be too difficult, although it would probably take some trial and error. For a novice user, doing that probably would be too difficult.

  With this new way of doing unattended installs, the only code that you need to write is the code for your deployee configuration (the NixOS configuration that you are going install onto a system). Once you have a deployee configuration that uses disko for its disk partitions, you just have to run a single command in order to generate an unattended install ISO:

  nixos-rebuild build-image --image-variant disko-unattended-install-iso

  Creating a deployee configuration and then running that one command is something that both experienced and novice users can do.

• The old way of doing unattended installs was not directly documented. Instead, you had to look at some loose instructions for how to do offline installations and determine for yourself how to use the information that you learned in order to do unattended installations.

  This new way of doing unattended installs is thoroughly documented in docs/unattended-install.md.

• With the old way of doing unattended installs, you needed to manually create two separate NixOS configurations.

  With this new way of doing unattended installs, you only need to manually create one NixOS configuration.

• With the old way of doing unattended installs, the deployee configuration gets evaluated at least twice. First, the deployee configuration is evaluated when the unattended install medium is created. Then, the deployee configuration gets reevaluated every time an unattended installation is performed (when disko-install is run).

  With this new way of doing unattended installs, the deployee configuration gets evaluated once when the unattended install medium is created. You can use that unattended install medium as many times as you want without ever having to reevaluate the deployee configuration.

• With the old way of doing unattended installs, the deployee configuration needs to do two things that are normally optional for NixOS configurations. Specifically, the deployee configuration needs to use disko for its disk partitions and filesystems, and the deployee configuration needs to be available as a flake output.

  With this new way of doing unattended installs, the deployee configuration only needs to do one thing that is normally optional for NixOS configurations. Specifically, the deployee configuration only needs to use disko for its disk partitions and filesystems.

• With the old way of doing unattended installs, you need to specify the same disk(s) twice in different locations. The first time is in the deployee configuration as disko.devices.disk.<name>.device = "<path>";. The second time is in the unattended installer configuration as command-line arguments for disko-install.

  With this new way of doing unattended installs, you only need to declare disks once.

This pull request is an alternative to #1223.

Closes #606. Closes #1223.

[Jayman2000]

I just pushed a new version of this pull request. Here’s what I changed:

• I rebased the pull request on ff8702b (a newer commit from the master branch).

• The “Init disko.unattendedInstall.* NixOS module options” commit now adds a comment to flake.nix that explains why tests are skipped on x86_32 systems:

  diff --git a/flake.nix b/flake.nix
  index bef86ab..a2cc767 100644
  --- a/flake.nix
  +++ b/flake.nix
  @@ -96,7 +96,11 @@
           in
           # FIXME: aarch64-linux seems to hang on boot
           lib.optionalAttrs pkgs.stdenv.hostPlatform.isx86_64 (nixosTests // { inherit disko-install; })
  -        // lib.optionalAttrs (!pkgs.stdenv.hostPlatform.isx86_32) { inherit unattended-install-module; }
  +        # x86_32 is skipped because we need to create virtual machines that
  +        # have more than 2 GiB of RAM.
  +        // lib.optionalAttrs (!pkgs.stdenv.hostPlatform.isx86_32) {
  +          inherit unattended-install-module;
  +        }
           //
             pkgs.lib.optionalAttrs (!pkgs.stdenv.buildPlatform.isRiscV64 && !pkgs.stdenv.hostPlatform.isx86_32)
               {

• The unattended-install-iso flake check no longer exists for aarch64-linux because it failed to build for reasons that do not seem related to this pull request.

I still don’t know what to do about the two aarch64-darwin failures though. The logs for both of them end with something like this:

Failed to find a machine for remote build!
derivation: d4x9k7325b1zr3ikz78w6ad2045fzr0j-vm-test-run-disko-unattended-install-iso-test.drv
required (system, features): (aarch64-darwin, [apple-virt, nixos-test])
3 available machines:
(systems, maxjobs, supportedFeatures, mandatoryFeatures)
([aarch64-darwin, x86_64-darwin], 8, [big-parallel, recursive-nix], [])
([i686-linux, x86_64-linux], 128, [big-parallel, kvm, nixos-test, recursive-nix, uid-range], [])
([aarch64-linux], 128, [big-parallel, kvm, nixos-test, recursive-nix, uid-range], [])
error: Cannot build '/nix/store/d4x9k7325b1zr3ikz78w6ad2045fzr0j-vm-test-run-disko-unattended-install-iso-test.drv'.
       Reason: platform mismatch
       Required system: 'aarch64-darwin'
       Current system: 'x86_64-linux'
       Reason: missing system features
       Required features: {apple-virt, nixos-test}
       Available features: {benchmark, big-parallel, ca-derivations, kvm, nixos-test, recursive-nix, uid-range}

That doesn’t look like a problem with any of the code that I added. Instead, it looks like a problem with the CI system. If the CI system can’t find a system with the required features to build something, then that shouldn’t really count as a failure. Instead, it should count as something along the lines of “I don’t know if this would be a success or a failure.” So, I don’t really know what to do about those two failures.