| 17 Feb 2024 |
 lassulus | whats the issue with that? | 04:54:04 |
 matthewcroughan | I suppose nothing if you know the solution, it's discovering the solution that is why it's worth supporting legacy | 04:54:19 |
| matthewcroughan | but yeah, if we can be a leading example of the solutions, then that works best | 04:54:49 |
| matthewcroughan | Okay.. other things.. How about we try to make the image builder use binfmt inside the VM, so that we can build disk images for arm64 on an x86 host successfully? :D | 04:55:19 |
| lassulus | but hybrid gpt/mbr is only useful if you bootloader doesn't support gpt. and there is a fallback to mbr. but if uboot supports efi than it doesn't need to care for the mbr stuff? | 04:55:56 |
| lassulus | we should debug first where all the memory is eaten up :P | 04:56:16 |
| matthewcroughan | lol, zram also "fixes" that :D | 04:56:29 |
| lassulus | pff | 04:56:34 |
| matthewcroughan | it works, undeniably | 04:56:41 |
| matthewcroughan | but still would be good to know where it is being used | 04:56:56 |
| matthewcroughan | In reply to @lassulus:lassul.us
but hybrid gpt/mbr is only useful if you bootloader doesn't support gpt. and there is a fallback to mbr. but if uboot supports efi than it doesn't need to care for the mbr stuff? the raspberry pi has boot firmware that only supports loading from mbr fat32, bootcode.bin must reside there | 04:57:21 |
| lassulus | it should work with 512m in the vm | 04:57:24 |
| matthewcroughan | In reply to @lassulus:lassul.us
it should work with 512m in the vm yeah and I'm saying that tests that fail with 512M without zram, succeed with zram | 04:58:13 |
| matthewcroughan | which makes me question why we don't just enable zram generally in all VMs | 04:58:27 |
| lassulus | that sounds like a bug | 04:58:30 |
| matthewcroughan | well yeah, it's not good to mask issues, but it made me wonder how it could also improve performance | 04:58:47 |
| matthewcroughan | would a test that never fails, but reports used memory in the VM be a useful thing? | 05:00:19 |
| matthewcroughan | do we have a test that reports information and does not fail right now? | 05:00:47 |
| lassulus | not yet | 05:01:09 |
| matthewcroughan | maybe I should make a test that fails if the VM ever consumes more than 512 instead | 05:01:18 |
| matthewcroughan | Are there not tests already failing like this? | 05:01:36 |
| lassulus | well first it would be nice to profile the build and see what consumes the memory | 05:01:41 |
| lassulus | the tests seem to work | 05:01:49 |
| lassulus | with the default amount of memory | 05:01:54 |
| matthewcroughan | Yeah I think it was something I did that caused it, hmm | 05:02:01 |
| 18 Feb 2024 |
|  hxr404 ✨ [it/she] changed their display name from hxr404 ✨ (they/them) to hxr404 ✨ [they/them] (offline). | 00:19:33 |
| hxr404 ✨ [it/she] | Heyy :3
Is it somehow possible to set up bind mounts via disko?
I tried
nodev = {
"/nix/store" = {
fsType = "tmpfs";
device = "/data/local/nix/store";
mountOptions = [ "bind" ];
};
}
doesn't throw an error, but also sadly doesn't do anything :(
| 00:36:34 |
| hxr404 ✨ [it/she] | * Heyy :3
Is it somehow possible to set up bind mounts via disko?
I tried
nodev = {
"/nix/store" = {
fsType = "tmpfs";
device = "/data/local/nix/store";
mountOptions = [ "bind" ];
};
};
doesn't throw an error, but also sadly doesn't do anything :(
| 00:37:08 |
| hxr404 ✨ [it/she] | * Heyy :3
Is it somehow possible to set up bind mounts via disko?
I tried
disko.devices.nodev = {
"/nix/store" = {
fsType = "tmpfs";
device = "/data/local/nix/store";
mountOptions = [ "bind" ];
};
};
doesn't throw an error, but also sadly doesn't do anything :(
| 00:40:42 |
| lassulus |
usually bind mounts are just managed with fileSystems.${target} = { device = src; options = [ "bind" ]; }; | 01:55:05 |
