| 19 May 2024 |
 matthewcroughan | * This same problem would be solved by running the vmTools on the hostPlatform, and allowing it to do binfmt, instead of treating the VM performing the disk partitioning/formatting as something that needs to run on the system arch of the nixosConfig | 18:38:37 |
| matthewcroughan | My next project was going to be making images for visionfivev1/2 | 18:42:05 |
| matthewcroughan | * My next project was going to be making images for visionfivev1/2 that boot with bcachefs too | 18:42:13 |
| matthewcroughan | Is this perhaps another way that disko's architecture fails because of the hostPlatform issue?
corpo-disko-images> qemu-system-aarch64: could not load kernel '/nix/store/fqwx7jpif67dzqhiggnnj69nhch8jp23-kernel-modules/vmlinuz.efi'
error: build of '/nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv' on 'ssh-ng://matthewcroughan@aarch64.nixos.community' failed: builder for '/nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv' failed with exit code 1;
last 2 log lines:
> unable to handle EFI zboot image with "zstd22" compression
> qemu-system-aarch64: could not load kernel '/nix/store/fqwx7jpif67dzqhiggnnj69nhch8jp23-kernel-modules/vmlinuz.efi'
For full logs, run 'nix log /nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv'.
| 20:51:22 |
| matthewcroughan | Why does disko care? | 20:51:25 |
| matthewcroughan | disko is trying to load the kernel from my nixosConfig, but why? That should only be relevant for an installTest if anything | 20:53:51 |
| matthewcroughan | Yes.. inheriting the kernel from the host is not quite right https://github.com/nix-community/disko/blob/master/lib/make-disk-image.nix#L13 | 21:11:43 |
| matthewcroughan | https://github.com/qemu/qemu/blob/master/hw/core/loader.c#L924 | 21:18:14 |
| matthewcroughan | Anything other than a gzipped kernel is not supported in QEMU | 21:18:31 |
| matthewcroughan | FFFFFFFFFFFFFF | 21:18:34 |
| matthewcroughan | Although it does highlight that disko shouldn't be using the target kernel, just to make the disk image for the target | 21:19:38 |
| matthewcroughan | It was me who implemented that though, so I should feel bad | 21:44:38 |
| matthewcroughan | https://github.com/nix-community/disko/pull/467 | 21:44:53 |
| matthewcroughan | The solution is uefi, but is there a use case for not using UEFI? | 22:05:38 |
| matthewcroughan | I can make the PR, but wondering if I should make it boolean | 22:06:10 |
| 20 May 2024 |
| matthewcroughan | https://github.com/nix-community/disko/pull/643 | 08:46:42 |
| matthewcroughan | Closer to finding memory leaks.. | 09:34:35 |
| matthewcroughan | I switched to systemd-boot from generic-extlinux, and now I'm getting the "Cannot allocate memory" all the time | 09:34:50 |
| matthewcroughan | increasing memory to 16384 fixed it | 09:40:09 |
| matthewcroughan | corpo-disko-images> setting up /etc...
corpo-disko-images> Initializing machine ID from random generator.
corpo-disko-images> File system "/boot" is not a FAT EFI System Partition (ESP) file system.
corpo-disko-images> Traceback (most recent call last):
corpo-disko-images> File "/nix/store/hk9khalas7ig9lpd8xygb00jgx9kjv2d-4d4f3f52hgwgk63d4fjg1rj4c1jdg9mn-systemd-boot", line 394, in <module>
corpo-disko-images> main()
corpo-disko-images> File "/nix/store/hk9khalas7ig9lpd8xygb00jgx9kjv2d-4d4f3f52hgwgk63d4fjg1rj4c1jdg9mn-systemd-boot", line 377, in main
corpo-disko-images> install_bootloader(args)
corpo-disko-images> File "/nix/store/hk9khalas7ig9lpd8xygb00jgx9kjv2d-4d4f3f52hgwgk63d4fjg1rj4c1jdg9mn-systemd-boot", line 292, in install_bootloader
corpo-disko-images> subprocess.check_call([f"{SYSTEMD}/bin/bootctl", f"--esp-path={EFI_SYS_MOUNT_POINT}"] + bootctl_flags + ["install"])
corpo-disko-images> File "/nix/store/vbfsfi87f7ks3hndbvn72n4334f9xll0-python3-3.11.9/lib/python3.11/subprocess.py", line 413, in check_call
corpo-disko-images> raise CalledProcessError(retcode, cmd)
corpo-disko-images> subprocess.CalledProcessError: Command '['/nix/store/wh5wyrs4nxdx7kh3ip0psn11rc2kknl1-systemd-255.4/bin/bootctl', '--esp-path=/boot', '--no-variables', 'install']' returned non-zero exit status 1.
| 09:40:12 |
| matthewcroughan | And then I see this for the first time, which is good. It warns me that my FS hasn't got the right type | 09:40:38 |
| matthewcroughan | but this part of the build never arrives unless I increase the memory size | 09:40:51 |
| matthewcroughan | though the "Cannot allocate memory" errors come from cp.. actually. | 09:41:18 |
| matthewcroughan | The bootloader install is probably calling cp, | 09:41:38 |
| matthewcroughan | * The bootloader install is probably calling cp | 09:41:40 |
| matthewcroughan | corpo-disko-images> + /nix/store/gc39rhvazg28s7y80c4c0a24x3hsv92p-postMountHook.sh
corpo-disko-images> + rm -rf /tmp/tmp.qOc2Qrmj2x
corpo-disko-images> warning: the group 'nixbld' specified in 'build-users-group' does not exist
corpo-disko-images> cp: cannot access '/nix/store/flqdgxi79hgv69k8vc1rdcxvn30m0i3r-perl5.38.2-HTTP-Cookies-6.10': Cannot allocate memory
corpo-disko-images> cp: cannot access '/nix/store/fzh5aadrdl76f7cn930ls979x6cgblyd-libsoup-2.74.3/share/locale/gl/LC_MESSAGES': Cannot allocate memory
| 09:41:58 |
| 21 May 2024 |
|  bumperboat changed their display name from bumperboat (UTC+8) to bumperboat (UTC+7). | 04:34:19 |
| matthewcroughan | lassulus: any comments on https://github.com/nix-community/disko/pull/643 ? | 11:31:00 |
| matthewcroughan | I didn't really think it's worth setting up a boolean, since it passes all the tests and I can't yet imagine a use-case where you'd want to disable EFI, especially given that legacy types are not supported in disko properly anymore | 11:31:46 |
|  Tanja (she/her) joined the room. | 11:37:13 |
