| 14 Mar 2026 |
 matthewcroughan | * and a lot of postmarketOS code exists to do the same | 18:20:55 |
| matthewcroughan | perhaps we could have an auto calculating implementation for each supported FS in disko | 18:21:18 |
| matthewcroughan | and if your FS doesn't support auto calculation, then tough luck, set the imageSize | 18:22:06 |
 lassulus | question is where the size is allocated, is it only /nix/store? what happens if you have something like size = "10%" in there? do we make the diskImage 10x your close size? | 18:22:52 |
| matthewcroughan | imageSize = "10%" ? | 18:23:29 |
| lassulus | what happens if you have size = "1G" for your /nix/store partition? just error out? | 18:23:40 |
| matthewcroughan | ah I see, uh | 18:24:02 |
| matthewcroughan | zfs = {
size = "100%";
content = {
type = "zfs";
pool = "edpool";
};
};
| 18:24:11 |
| 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 |
