Hi all, struggling though the docs _create zfs* options I eventually got the disko config to work. However, because I have used encrypted zfs root and /nix datasets (across different pools) I have encountered a dependency issue (I think) on boot.
`
zpool = {
zroot = {
type = "zpool";
mode = {
topology={
type = "topology";
vdev = [
{
members = [ "crucialMx500500g1" ];
}
];
};
};
options = {
# Workaround: cannot import 'zroot': I/O error in disko tests
cachefile = "none";
ashift = "12";
};
rootFsOptions = {
mountpoint = "none";
compression = "lz4";
acltype = "posixacl";
xattr = "sa";
atime = "off";
};
postCreateHook = "zfs list -t snapshot -H -o name | grep -E '^zroot@blank$' || zfs snapshot zroot@blank";
datasets = {
root = {
type = "zfs_fs";
mountpoint = "/";
options = {
encryption = "aes-256-gcm";
keyformat = "passphrase";
keylocation = "prompt";
};
};
};
};
# };

    fast = {
      type = "zpool";
      mode = {
      topology={
        type = "topology";
        vdev = [
          {
            mode = "mirror";
            members = [ "samsung990Pro4t1" "samsung990Pro4t2" ];
          }
        ];
      };
      };
      mountpoint = "/mnt/fast";
      options = {
        ashift = "12";
      };
      rootFsOptions = {
        mountpoint = "none";
        atime = "off";
        compression = "lz4";

        encryption = "aes-256-gcm";
        keyformat = "hex";
        keylocation = "file:///etc/zfs/keys/fast.hex";
      };
      datasets = {
        nix = {
          type = "zfs_fs";
          mountpoint = "/nix";
          options = {
           compression = "zstd";
          };
        };
        game = {
          type = "zfs_volume";
          size = "1T";
          options = {
            volblocksize = "128K";
          };
          # content = {
          #   type = "filesystem";
          #   format = "ntfs";
          # };
        };
      };
    };
  };

`
Based on the stage 1 boot messages, initrd/linux is loading the key zroot/root via a passphrase, then loading the fast pool key. It can't since the fast pool key is in the zroot/root pool. After failing to load the key it then mounts zroot/root which then now makes the key available.
I have found https://github.com/nix-community/disko/issues/141 but the linked https://github.com/nix-community/disko/pull/218/files only affects creation it seems. Any help would be appreciated.

Hi all, struggling though the docs _create zfs* options I eventually got the disko config to work. However, because I have used encrypted zfs root and /nix datasets (across different pools) I have encountered a dependency issue (I think) on boot.

`
Based on the stage 1 boot messages, initrd/linux is loading the key zroot/root via a passphrase, then loading the fast pool key. It can't since the fast pool key is in the zroot/root pool. After failing to load the key it then mounts zroot/root which then now makes the key available.
I have found https://github.com/nix-community/disko/issues/141 but the linked https://github.com/nix-community/disko/pull/218/files only affects creation it seems. Any help would be appreciated.

Hi all, struggling though the docs _create zfs* options I eventually got the disko config to work. However, because I have used encrypted zfs root and /nix datasets (across different pools) I have encountered a dependency issue (I think) on boot.

      zpool = {
        zroot = {
          type = "zpool";
          mode = {
          topology={
            type = "topology";
            vdev = [
              {
                members = [ "crucialMx500500g1" ];
              }
            ];
          };
          };
          options = {
            # Workaround: cannot import 'zroot': I/O error in disko tests
            cachefile = "none";
            ashift = "12";
          };
          rootFsOptions = {
            mountpoint = "none";
            compression = "lz4";
            acltype = "posixacl";
            xattr = "sa";
            atime = "off";
          };
          postCreateHook = "zfs list -t snapshot -H -o name | grep -E '^zroot@blank$' || zfs snapshot zroot@blank";
          datasets = {
            root = {
              type = "zfs_fs";
              mountpoint = "/";
              options = {
                encryption = "aes-256-gcm";
                keyformat = "passphrase";
                keylocation = "prompt";
              };
            };
          };
        };
        # };

        fast = {
          type = "zpool";
          mode = {
          topology={
            type = "topology";
            vdev = [
              {
                mode = "mirror";
                members = [ "samsung990Pro4t1" "samsung990Pro4t2" ];
              }
            ];
          };
          };
          mountpoint = "/mnt/fast";
          options = {
            ashift = "12";
          };
          rootFsOptions = {
            mountpoint = "none";
            atime = "off";
            compression = "lz4";

            encryption = "aes-256-gcm";
            keyformat = "hex";
            keylocation = "file:///etc/zfs/keys/fast.hex";
          };
          datasets = {
            nix = {
              type = "zfs_fs";
              mountpoint = "/nix";
              options = {
               compression = "zstd";
              };
            };
            game = {
              type = "zfs_volume";
              size = "1T";
              options = {
                volblocksize = "128K";
              };
              # content = {
              #   type = "filesystem";
              #   format = "ntfs";
              # };
            };
          };
        };
      };

Based on the stage 1 boot messages, initrd/linux is loading the key zroot/root via a passphrase, then loading the fast pool key. It can't since the fast pool key is in the zroot/root pool. After failing to load the key it then mounts zroot/root which then now makes the key available.
I have found https://github.com/nix-community/disko/issues/141 but the linked https://github.com/nix-community/disko/pull/218/files only affects creation it seems. Any help would be appreciated.

In reply to @lassulus:lassul.us
hmm, it looks like a nixpkgs bug