| 14 Mar 2026 |
 matthewcroughan | is what I have right now | 18:24:14 |
| matthewcroughan | * zfs = {
size = "100%";
content = {
type = "zfs";
pool = "edpool";
};
};
| 18:24:19 |
 lassulus | yes, that is the trivial case :) | 18:24:24 |
| matthewcroughan | error: A definition for option disko.devices.disk.disk1.content.partitions.zfs.size' is not of type value "100%" (singular enum) or str… ┃ - In /nix/store/g8pkz1bxk5n7vvicr9nk0wklgrqp0k9y-source/hosts/ed/disko.nix': "10%` | 18:24:43 |
| lassulus | don't think zfs can do other sizes than 100% or fixed block size | 18:25:25 |
| lassulus | lvm can do other % | 18:25:33 |
| matthewcroughan | You can set 1G | 18:25:38 |
| matthewcroughan | the only reason I'm using this image builder is because I don't trust the diskoScript to do the right thing, on my laptop | 18:27:38 |
| matthewcroughan | Running the diskoScript on an existing machine is fine, except in the case of zfs where weird things happen because of pool names | 18:27:57 |
| matthewcroughan | And also nixos-install on a running machine is weird too, I've had it fsck up because it installed the bootloader for the target into my real /boot | 18:28:37 |
| lassulus | I guess we could write a script that copies the closure into the image and it can check before it runs if there is enough space, since it's easier to do this when everything is mounted | 18:30:26 |
| lassulus | would still be a build time error | 18:30:38 |
| lassulus | but we could raise a better error message | 18:30:45 |
| matthewcroughan | At the great cost of build time | 18:31:34 |
| matthewcroughan | You're going to 2x the build time if you do that | 18:31:43 |
| matthewcroughan | just for a check | 18:31:47 |
| matthewcroughan | The image builder as-is is pretty snappy, but copying the large toplevel twice is going to make that experience worse | 18:32:31 |
| matthewcroughan | lassulus: Even after increasing the imageSize I continue to run into this issue:
ed-disko-images> cp: cannot access '/nix/store/70yigs2nzcjv8iwqf5xmlhqcyp9fyy8s-qemu-10.2.1-ga': Cannot allocate memory
ed-disko-images> [ 15.769579] virtio-fs: virtio_fs_enqueue_req() failed -12
ed-disko-images> cp: cannot access '/nix/store/7w2ymzbr4xqvf7527l9halmqf0hq5xy0-intel-compute-runtime-26.05.37020.3': Cannot allocate memory
ed-disko-images> [ 17.223740] virtio-fs: virtio_fs_enqueue_req() failed -12
ed-disko-images> cp: cannot access '/nix/store/8wz0w5c36wb30wx08grryjzzvjw07rbv-graphics-drivers/lib/gbm': Cannot allocate memory
| 18:32:56 |
| lassulus | ah yeah, the memory thingie | 18:33:11 |
| lassulus | not sure what triggers it, if you have a small nix expression reproducer I can debug it | 18:33:27 |
| matthewcroughan | VMs just are not the way to go for image building | 18:33:32 |
| matthewcroughan | FS as lib is, like repart | 18:33:42 |
| lassulus | but there are soo many different FS | 18:33:52 |
| lassulus | don't want to reimplement all of them :D | 18:34:04 |
| matthewcroughan | True, I suppose VMs allow disko to support BSD and other FS types | 18:34:21 |
| matthewcroughan | even macos or windows FS if you really wanted to | 18:34:41 |
| matthewcroughan | with nixbsd, actually supporting that with disko isn't out of the question today | 18:35:02 |
| lassulus | also something like ZFS is not supported as lib I think | 18:35:05 |
| matthewcroughan | I don't run into the "Cannot allocate memory" issue if I increase the memSize to 16384 | 18:37:09 |
| matthewcroughan | though I of course see my memory usage go up massively on my host | 18:37:22 |
