| 16 Feb 2024 |
 palo | Hmm, this worked a while ago, and it's used in the examples?
| 20:30:22 |
| palo | * Hmm, this worked a while ago, and it's used in the examples?
error: The option `disko.devices.disk.sda.content.partitions."[definition 1-entry 2]".size' does not exist.
| 20:30:57 |
| palo | https://git.ingolf-wagner.de/palo/nixos-config/src/branch/main/nixos/machines/orbi/disko-config.nix#L42 < that's the line that is wrong. | 20:32:13 |
| palo | Hmm in the examples partitions is a attrs but When I do that. I get :
A definition for option `disko.devices.disk.sda.content.partitions' is not of type `list of (submodule)'.
| 20:46:01 |
| palo | Ok replacing size with end worked. | 20:54:56 |
| 17 Feb 2024 |
 matthewcroughan | lassulus: To explain the problem I found with hybrid, and why legacy is worth supporting, doing hybrid causes small issues with u-boot | 04:53:23 |
| matthewcroughan | specifically, if you have a hybrid data structure, it loads u-boot in GPT mode | 04:53:37 |
| matthewcroughan | in GPT mode, the MBR partitions cannot be seen | 04:53:44 |
 lassulus | that sounds like the intended use? | 04:53:58 |
| matthewcroughan | Sort of a problem with U-Boot, and it can be worked around, but it's such a PITA | 04:54:03 |
| 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 |
