!oNSIfazDqEcwhcOjSL:matrix.org

disko

353 Members
disko - declarative disk partitioning - https://github.com/nix-community/disko89 Servers

Load older messages


SenderMessageTime
7 Feb 2025
@ian:rainingmessages.devian joined the room.14:53:24
@brian:bmcgee.ie@brian:bmcgee.iein nixos vm tests is there a way to force the disk uuid to be the same/consistent?15:12:15
8 Feb 2025
@terrorjack:matrix.orgterrorjack joined the room.01:22:28
@lassulus:lassul.uslassulusyou can set the uuids now in the config, maybe that is sufficient?01:49:21
@terrorjack:matrix.orgterrorjack set a profile picture.02:24:27
@terrorjack:matrix.orgterrorjack removed their profile picture.02:25:02
@therajesq:matrix.orgZamyatin joined the room.23:52:02
9 Feb 2025
@projectinitiative:matrix.orgprojectinitiative joined the room.04:00:12
@projectinitiative:matrix.orgprojectinitiative

Hi,
I am trying to add a new feature for multi-drive bcachefs support. I am attempting to model it after zfs and mdadm/mdraid.
When I attempt to build the check nix build .\#checks.x86_64-linux.bcachefs-multi-disk.driverInteractive

I run into the following error:

       > In /nix/store/v86q00ycq0a1vlwa6fhx3hims0mxj0a7-disko-mount line 140:
       >     readarray -t pool_devices < <(cat "$disko_devices_dir"/bcachefs_pool1)
       >                                        ^----------------^ SC2154 (warning): disko_devices_dir is referenced but not assigned

I know this gets preset before hand (and injected?) in lib/default.nix's _create method. I believe I have added the necessary type to that file as well. Curious if someone had more insight on how this arch works/what vars are provided to types.

Here is my lib/default: https://github.com/ProjectInitiative/disko/blob/feat/bcachefs-as-member/lib/default.nix#L37

04:08:31
@projectinitiative:matrix.orgprojectinitiativeI think I can answer my own question: topLevel only includes this var for _create methods. I have it in a _mount. I will need to rework some of the logic05:09:32
@tired:fairydust.space@tired:fairydust.space left the room.22:51:59
10 Feb 2025
@snipped-paws:matrix.orgsnipped-paws joined the room.05:51:00
@snipped-paws:matrix.orgsnipped-pawsRedacted or Malformed Event05:56:41
@snipped-paws:matrix.orgsnipped-paws

Hello, I am new-ish to NixOS and disko and am trying to get a setup working for my home server. I have this cut-down config that is just supposed to format the single mirror that I plan to install NixOS on top of, but it seems to not correctly create the zfs partition (as well as the zpool and datasets). When I run sudo disko --mode disko disko-config.nix, it appears to work (?), but when I check the partitions in Gnome Disks in the live environment, the content of the partition is listed as "Unknown." The EFI boot partition does appear to be recognized as expected. Any help would be much appreciated!

{
  disko.devices = let
    nixosPartitions = {
      ESP = {
        size = "512M";
        type = "EF00";
        content.type = "filesystem";
        content.format = "vfat";
        content.mountpoint = "/boot";
      };
      zfs = {
        size = "100%";
        content.type = "zfs";
        content.pool = "nixos";
      };
    };
  in {
    disk = {
      # NixOS boot mirror (240GBx2)
      ssd0 = {
        device = "/dev/sda";
        type = "disk";
        content = {
          type = "gpt";
          partitions = nixosPartitions;
        };
      };
      ssd1 = {
        device = "/dev/sdb";
        type = "disk";
        content = {
          type = "gpt";
          partitions = nixosPartitions;
        };
      };
    };
  };

  zpool = {
    # NixOS boot mirror
    nixos = {
      type = "zpool";
      mode = "mirror";
      options = { ashift = "12"; };
      datasets = {
        "root" = {
          type = "zfs_fs";
          mountpoint = "/";
          options = {
            encryption = "aes-256-gcm";
            keyformat = "passphrase";
            keylocation = "prompt";
          };
        };
        "nix" = {
          type = "zfs_fs";
          mountpoint = "/nix";
          options."com.sun:auto-snapshot" = "false";
        };
        "home" = {
          type = "zfs_fs";
          mountpoint = "/home";
          options = {
            encryption = "aes-256-gcm";
            keyformat = "raw";
            keylocation = "file:///etc/zfskey";
          };
        };
      };
    };
  };
}
06:10:38
@lassulus:lassul.uslassulusGnome disks can't show zfs partitions07:16:56
@lassulus:lassul.uslassulusAfaik07:17:01
@snipped-paws:matrix.orgsnipped-paws

I've managed to make a little more progress:

{
  disko.devices = let
    nixosPartitions = {
      ESP = {
        size = "512M";
        type = "EF00";
        content.type = "filesystem";
        content.format = "vfat";
        content.mountpoint = "/boot";
      };
      zfs = {
        size = "100%";
        content.type = "zfs";
        content.pool = "zpool-nixos";
      };
    };
  in {
    disk = {
      # NixOS boot mirror (240GBx2)
      ssd0 = {
        device = "/dev/sda";
        type = "disk";
        content = {
          type = "gpt";
          partitions = nixosPartitions;
        };
      };
      ssd1 = {
        device = "/dev/sdb";
        type = "disk";
        content = {
          type = "gpt";
          partitions = nixosPartitions;
        };
      };
    };

    zpool = {
      # NixOS boot mirror
      zpool-nixos = {
        type = "zpool";
        mode = "mirror";
        options = { ashift = "12"; };
        preCreateHook = ''
          # Create the temporary keyfile before any ZFS dataset is created
          head -c 32 /dev/urandom > /run/tmp-zfskey
          chmod 600 /run/tmp-zfskey
        '';
        datasets = {
          "root" =
            { # NOTE: Don't encrypt root dataset directly to allow flexibility later.
              type = "zfs_fs";
              mountpoint = "/";
            };
          "root/unlock" = {
            type = "zfs_fs";
            mountpoint = "/unlock";
            options = {
              encryption = "aes-256-gcm";
              keyformat = "passphrase";
              keylocation = "prompt";
            };
          };
          "root/nix" = {
            type = "zfs_fs";
            mountpoint = "/nix";
            options = {
              encryption = "aes-256-gcm";
              keyformat = "raw";
              keylocation = "file:///run/tmp-zfskey";
            };
          };
          "root/home" = {
            type = "zfs_fs";
            mountpoint = "/home";
            options = {
              encryption = "aes-256-gcm";
              keyformat = "raw";
              keylocation = "file:///run/tmp-zfskey";
            };
          };
        };
        postCreateHook = ''
          # Move the keyfile into the unlock dataset
          # cp /run/tmp-zfskey /mnt/unlock/zfskey
          # chmod 600 /mnt/unlock/zfskey

          echo "postCreateHook running" >> /tmp/disko-debug.log
          ls -lah /mnt/unlock >> /tmp/disko-debug.log 2>&1
          echo "before" >> /tmp/disko-debug.log 2>&1
          cp /run/tmp-zfskey /mnt/unlock/zfskey >> /tmp/disko-debug.log 2>&1
          echo "after" >> /tmp/disko-debug.log 2>&1
          chmod 600 /mnt/unlock/zfskey >> /tmp/disko-debug.log 2>&1
          ls -lah /mnt/unlock >> /tmp/disko-debug.log 2>&1

          # Update keylocation for other datasets (will be correct after reboot)
          zfs set keylocation=file:///unlock/zfskey zpool-nixos/root/nix
          zfs set keylocation=file:///unlock/zfskey zpool-nixos/root/home
        '';
      };
    };
  };
}

This mostly runs, but the postCreateHook has an issue with copying the key file. Not sure if I am going about this the right way, so any pointers would be much appreciated. I basically want to have just one dataset encrypted with a password, and then have all other encrypted datasets reference a key file stored on the password protected one so that I can unlock everything with just one password.

11:02:03
@projectinitiative:matrix.orgprojectinitiativeDoes anyone have an explanation on how the disk type and dependencies get tracked? Similar to how for mdadm and mdraid, mdraid runs before mdadm as that is a prereq. I am trying to do something similar but running into issues13:31:25
@lassulus:lassul.uslassulusthere is deviceDependencies in _meta which gets exported and toposorted later13:36:10
@lassulus:lassul.uslassulusor later in that case when it's used13:36:26
@projectinitiative:matrix.orgprojectinitiativeHmm, I think I'm using that correctly. I am noticing one type's create method isn't executing at all. I added some debug statements to the shell script, and that's where I noticed my issue. Not at my computer atm, but I can send the example in a few 13:54:18
@projectinitiative:matrix.orgprojectinitiativehttps://github.com/ProjectInitiative/disko/blob/feat/bcachefs-as-member/lib/types/bcachefs_member.nix#L5714:33:37
11 Feb 2025
@projectinitiative:matrix.orgprojectinitiative

Are there any good examples of how to use the topsorted function? Doing some digging in nix repl for the mdadm example, I see this behavior:

nix-repl> inputs.nixpkgs.lib.lists.last nixosConfigurations.testmachine.config.disko.devices._meta.dev[
  "disk"
  "/dev/my-disk"
]

nix-repl> builtins.head nixosConfigurations.testmachine.config.disko.devices._meta.deviceDependencies.mdadm.raid1
[
  "disk"
  "/dev/my-disk"
]

Seems a bit odd only one element is in the list. And I wonder if this is why my new types are not getting ordered properly, because they follow the same structure as mdadm/mdraid.

14:16:26
@projectinitiative:matrix.orgprojectinitiative *

Are there any good examples of how to use the topsorted function? Doing some digging in nix repl for the mdadm example, I see this behavior:

nix-repl> inputs.nixpkgs.lib.lists.last nixosConfigurations.testmachine.config.disko.devices._meta.deviceDependencies.mdadm.raid1[
  "disk"
  "/dev/my-disk"
]

nix-repl> builtins.head nixosConfigurations.testmachine.config.disko.devices._meta.deviceDependencies.mdadm.raid1
[
  "disk"
  "/dev/my-disk"
]

Seems a bit odd only one element is in the list. And I wonder if this is why my new types are not getting ordered properly, because they follow the same structure as mdadm/mdraid.

14:16:59
@projectinitiative:matrix.orgprojectinitiative *

Are there any good examples of how to use the topsorted function? Doing some digging in nix repl for the mdadm example, I see this behavior:

nix-repl> inputs.nixpkgs.lib.lists.last nixosConfigurations.testmachine.config.disko.devices._meta.deviceDependencies.mdadm.raid1
[
  "disk"
  "/dev/my-disk"
]

nix-repl> builtins.head nixosConfigurations.testmachine.config.disko.devices._meta.deviceDependencies.mdadm.raid1
[
  "disk"
  "/dev/my-disk"
]

Seems a bit odd only one element is in the list. And I wonder if this is why my new types are not getting ordered properly, because they follow the same structure as mdadm/mdraid.

14:17:08
@projectinitiative:matrix.orgprojectinitiative *

Are there any good examples of how to use the sortDevicesByDependencies function? Doing some digging in nix repl for the mdadm example, I see this behavior:

nix-repl> inputs.nixpkgs.lib.lists.last nixosConfigurations.testmachine.config.disko.devices._meta.deviceDependencies.mdadm.raid1
[
  "disk"
  "/dev/my-disk"
]

nix-repl> builtins.head nixosConfigurations.testmachine.config.disko.devices._meta.deviceDependencies.mdadm.raid1
[
  "disk"
  "/dev/my-disk"
]

Seems a bit odd only one element is in the list. And I wonder if this is why my new types are not getting ordered properly, because they follow the same structure as mdadm/mdraid.

14:18:06
@lassulus:lassul.uslassulusit should just be the attribute you depend on, so in this case disko.devices.mdadm.raid1 depends on disko.devices.disk."/dev/my-disk"14:19:49
@lassulus:lassul.uslassulusand the toposort then sorts the snippet for disk."/dev/my-disk" before the snipper for mdadm.raid114:21:03
@lassulus:lassul.uslassulusbut if your raid depends on multiple disks, there should be multiple disks in there14:23:18
@projectinitiative:matrix.orgprojectinitiativelooking at example/mdadm.nix, two disks are defined with mdadm and then mdraid as the content, shouldn't both be included? I guess ultimately I am trying to figure out why my types that are modeled after the zfs and mdadm patterns are not respecting the same order when they get combined in the final _create. i.e. the mdraid equivalent bcachefs_member type (for members of the pool) needs to come first, yet it gets put after the bachefs type I made. Both types are nearly identical in structure14:23:25

Show newer messages


Back to Room ListRoom Version: 10