 | disko | 353 Members |
| disko - declarative disk partitioning - https://github.com/nix-community/disko | 89 Servers |
| disko | 353 Members |
| disko - declarative disk partitioning - https://github.com/nix-community/disko | 89 Servers |
| Sender | Message | Time |
|---|---|---|
| 11 Feb 2025 | ||
 projectinitiative | 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: 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 | * 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: 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 | * 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: 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 | * 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: 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 | it 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 | and the toposort then sorts the snippet for disk."/dev/my-disk" before the snipper for mdadm.raid1 | 14:21:03 |
| lassulus | but if your raid depends on multiple disks, there should be multiple disks in there | 14:23:18 |
| projectinitiative | looking 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 structure | 14:23:25 |
| projectinitiative | I will note I also tried with the zfs-with-vdevs example adding it to the test machine config, and it also only has one disk listed under dependencies despite having several listed in the example file under zroot | 14:24:54 |
| lassulus | hmm, maybe there is indeed a bug | 14:25:56 |
| lassulus | which didn't get triggered yet, but I thought the complex example would take care of that | 14:26:17 |
| projectinitiative | reproduction steps:
| 14:27:29 |
| projectinitiative | * reproduction steps:
| 14:27:59 |
| lassulus | I will try to add that to my thaigersprint todo list tomorrow :D | 14:28:16 |
| projectinitiative | Obligatory: I wish nix had better testing/debugging tools, this is taking way longer to nail down my overall issue haha... | 14:30:10 |
 shift | In reply to @lassulus:lassul.usYou want issues for your sprint? Haha | 20:09:11 |
| 12 Feb 2025 | ||
| lassulus | You have more? :D | 01:38:19 |
| projectinitiative | In reply to @lassulus:lassul.usI looked up that thaigersprint was, that seems unique. Talk about a cool experience | 03:48:41 |
| projectinitiative | * I looked up what thaigersprint was, that seems unique. Talk about a cool experience | 03:48:49 |
| lassulus | ok, deepMergeMap actually doesn't merge lists, since recursiveUpdate doesn't take care of that | 05:31:21 |
| lassulus | projectinitiative: https://github.com/nix-community/disko/pull/963 | 10:21:50 |
| projectinitiative | looks like this fixed the deviceDendencies list not showing up! I now just have to figure out why my type ordering is not working correctly. | 14:49:36 |
| lassulus | If you have a PR with the current state I could take a look tomorrowish | 15:17:11 |
 Sávio | Thanks for the comments on the binfmt PR. I'm still working on it | 17:27:57 |
| projectinitiative | Current state of my attempt: https://github.com/nix-community/disko/pull/961 | 18:42:48 |
| 13 Feb 2025 | ||
| projectinitiative | lassulus I think I discovered another bug. I fixed the issue by renaming my type to "dxcachefs" instead of "bcachefs" In the dependency sort list, if there are any types at alphabetically before the "disk" type, the sortDeviceDependencies function drops those at the top. So my pool object was getting collated as the very first entry in the _create functions. I don't think this was caught because mraid and zpool always appear at the end of the device dependency list due to their position in the alphabet. I think the function will need a specific check to always put disk device types at the beginning of the list | 22:30:01 |
| projectinitiative | | 22:31:20 |
| projectinitiative | * | 22:32:43 |
| projectinitiative | * | 22:33:28 |
| projectinitiative | * lassulus I think I discovered another bug. I fixed the issue by renaming my type to "dxcachefs" instead of "bcachefs" In the dependency sort list, if there are any types that are alphabetically before the "disk" type, the sortDeviceDependencies function drops those at the top. So my pool object was getting collated as the very first entry in the _create functions. I don't think this was caught because mraid and zpool always appear at the end of the device dependency list due to their position in the alphabet. I think the function will need a specific check to always put disk device types at the beginning of the list | 22:34:14 |