| 20 Sep 2024 |
 Mic92 | mannp ⚡️: are you missing block device drivers in your hardware-configuration.nix? | 13:42:43 |
|  mannp ⚡️ left the room. | 15:34:44 |
| Mic92 | also try nofail for debugging: https://github.com/Mic92/dotfiles/blob/5f4c782602e2f7ac89237fee62a874caba0a15cc/machines/turingmachine/modules/disko.nix#L17 | 13:43:26 |
| 21 Sep 2024 |
 matthewcroughan | Mic92: https://github.com/nix-community/disko/pull/465#issuecomment-2365230543 | 15:40:28 |
| matthewcroughan | what do you mean by "more accurate algorithm", what is currently inaccurate about it? | 15:40:39 |
| matthewcroughan | The PR works well, and functions correctly, it doesn't have any bugs that I'm aware of that cause invalid outputs (disk images that don't work) | 15:41:04 |
| Mic92 | Have you looked at the disk calculation that make-disk-image does? | 15:41:41 |
| Mic92 | It's way more than just using the closure size. | 15:41:52 |
| matthewcroughan | make-disk-image doesn't do calculation? It just asks you for an imageSize right now, doesn't it? | 15:42:16 |
| matthewcroughan | or do you mean in my PR? | 15:42:48 |
| Mic92 | I mean the implementation in nixpkgs | 15:43:25 |
| Mic92 | It's ext4 only afaik | 15:43:31 |
| matthewcroughan | what does that have to do with disko? | 15:43:33 |
| Mic92 | https://github.com/NixOS/nixpkgs/blob/636c5a8db5eb31a9ce04d0e75779ab684b0f8ae3/nixos/lib/make-disk-image.nix#L453 | 15:43:57 |
| matthewcroughan | ah okay so make-disk-image from nixpkgs has a complex thing, and my thing is too simple | 15:44:50 |
| matthewcroughan | and just using the path-info size is wrong in some way? | 15:45:01 |
| Mic92 | It's just the raw content and doesn't take into account that filesystem need more data structures for inodes and stuff. | 15:45:31 |
| matthewcroughan | I don't actually understand in what way it is wrong to just use the path-info -Sh output though, because it worked in my cases | 15:45:41 |
| matthewcroughan | In reply to @joerg:thalheim.io
It's just the raw content and doesn't take into account that filesystem need more data structures for inodes and stuff. Oh right, so for that I just hardcode a little bit more in, since I was unable to figure that out | 15:45:58 |
| matthewcroughan | I don't think that's a bad approach, to just +10M it | 15:46:07 |
| Mic92 | What about filesystem that do compression for example? | 15:46:35 |
| Mic92 | I was wondering if it wouldn't be better to increase the image everytime we run out of disk space. | 15:46:59 |
| matthewcroughan | What is more unsatisfying:
- A spare +10M at the end of the image
- An spare 5G and trial-and-error session that takes 30 minutes to figure out what the
imageSize should be
| 15:47:04 |
| Mic92 | I think most filesystem can be dynamically increased | 15:47:09 |
| matthewcroughan | * What is more unsatisfying:
- A spare +10M at the end of the image
- A spare 5G, or a trial-and-error session that takes 30 minutes to figure out what the
imageSize should be
| 15:47:33 |
| matthewcroughan | In using disko I just set the imageSize to a large incorrect value since I can't be bothered with the trial-and-error | 15:47:52 |
| matthewcroughan | In reply to @joerg:thalheim.io
I was wondering if it wouldn't be better to increase the image everytime we run out of disk space. Oh you mean some process inside the builder that identifies that there's no disk space avail, and expands it to fit? | 15:48:35 |
| Mic92 | Yes | 15:48:57 |
| matthewcroughan | That's pretty clever, and I wanted to do the same for NixThePlanet VMs lol | 15:49:02 |
| matthewcroughan | so if the builder fails, it'll try again until it succeeds, regarding the macos/windows builders not working 100% of the time because mac/win suck | 15:49:30 |
