In reply to @matthewcroughan:defenestrate.it
BMG: if you have imported Disko into a nixosConfiguration, then a VM Test is already present for that in system.build.toplevel.installTest

I can confirm the issue with nixos-install running out of memory still happens even with the latest disko and nix tooilng

evaluating derivation 'git+file:///home/matthew/git/nixcfg#nixosConfigurations.bpi-r4.config.syerror: build of '/nix/store/g952ci9c1fhdn61ybb71xd7yngspsbdk-homerouter-disko-images.drv' on 'ssh-ng://matthewcroughan@aarch64.nixos.community' failed: builder for '/nix/store/g952ci9c1fhdn61ybb71xd7yngspsbdk-homerouter-disko-images.drv' failed with exit code 123;
       last 10 log lines:
       > cp: cannot access '/nix/store/h60m1fwahjd2mv6gsg77ji3vb4gpj4dk-source/pkgs/applications/misc/tui-journal': Cannot allocate memory
       > cp: cannot access '/nix/store/h60m1fwahjd2mv6gsg77ji3vb4gpj4dk-source/pkgs/applications/misc/tuir': Cannot allocate memory
       > cp: cannot access '/nix/store/h60m1fwahjd2mv6gsg77ji3vb4gpj4dk-source/pkgs/applications/misc/tut': Cannot allocate memory
       > cp: cannot access '/nix/store/h60m1fwahjd2mv6gsg77ji3vb4gpj4dk-source/pkgs/applications/misc/tuxclocker': Cannot allocate memory
       > cp: cannot access '/nix/store/ia3ymz0pcg0w31091fb3w9jld3qa1kgp-util-linux-2.39.4-lib/share/locale/de/LC_MESSAGES': Cannot allocate memory
       > cp: cannot access '/nix/store/ia3ymz0pcg0w31091fb3w9jld3qa1kgp-util-linux-2.39.4-lib/share/locale/es': Cannot allocate memory
       > cp: cannot access '/nix/store/ia3ymz0pcg0w31091fb3w9jld3qa1kgp-util-linux-2.39.4-lib/share/locale/et': Cannot allocate memory
       > cp: cannot access '/nix/store/kgdz4hwrdf6mir55xzmgmdnf9z75jm3l-tzdata-2024a/share/zoneinfo/right/Mexico': Cannot allocate memory
       > cp: cannot access '/nix/store/l7gmwp99pwx2s20hy3hzhva0vxzpcwa9-systemd-minimal-256.2/share/dbus-1/services': Cannot allocate memory
       > [  152.515840] reboot: Power down
       For full logs, run 'nix log /nix/store/g952ci9c1fhdn61ybb71xd7yngspsbdk-homerouter-disko-images.drv'.

Hi all. Is there a way to ensure a certain disk is processed first in a disko configuration? I have a detached-header LUKS setup that encrypts my internal disks and writes their headers to an USB device. Disko does encrypt both devices, but it processes the USB last, and it does so by deleting the headers and repartitioning. Is there a way to ensure it formats the USB before installing the headers?

Sorry, I was looking for the priority option.

Hi all. Is there a way to ensure a certain disk is processed first in a disko configuration? I have a detached-header LUKS setup that encrypts my internal disks and writes their headers to an USB device. Disko does encrypt both devices, but it processes the USB last, and it does so by deleting the headers and repartitioning. Is there a way to ensure it formats the USB before installing the headers?

Sorry, I was looking for the priority option.

Something is up with udev; the disk ID isn't a link to /dev/sdb. Not a disko issue though.

Something is up with udisks; the disk ID isn't a link to /dev/sdb. Not a disko issue though.

ok so I guess what I want to happen is for when I run nixos-anywhere ... --vim-test on a Mac, I want it to build the VM on an aarch64-linux remote builder, but then run the final test (boot the thing and whatever) by running qemu directly on the Mac.

But right now that test lives inside the nixosConfiguration, as <machine>.system.build.installTest, which means of course that it is also aarch64-linux, so that final qemu invocation is still running under my aarch64-linux builder

which sucks because that doesn't have any working qemu accelerators other than tcg

ok so I guess what I want to happen is for when I run nixos-anywhere ... --vm-test on a Mac, I want it to build the VM on an aarch64-linux remote builder, but then run the final test (boot the thing and whatever) by running qemu directly on the Mac.

But right now that test lives inside the nixosConfiguration, as <machine>.system.build.installTest, which means of course that it is also aarch64-linux, so that final qemu invocation is still running under my aarch64-linux builder

which sucks because that doesn't have any working qemu accelerators other than tcg

for now I'm doing my local testing a little more manually, with some customized install media that mounts the repo containing my NixOS config using a VirtFS share

if I can figure it out, though, would moving disko to use pkgs.nixosTest instead of make-test-python.nix as its entrypoint for NixOS vm-tests, and then modifying nixos-anywhere.sh to support running that test locally be an agreeable change?

for now I'm doing my local testing a little more manually, with some customized install media that mounts the repo containing my NixOS config using a VirtFS share and includes disko and nixos-anywhere on it

if I can figure it out, though, would moving disko to use pkgs.nixosTest instead of make-test-python.nix as its entrypoint for NixOS vm-tests, and then modifying nixos-anywhere.sh to support running that test locally be an agreeable change?

for now I'm doing my local testing a little more manually, with some customized install media that mounts the repo containing my NixOS config using a VirtFS share and includes disko and nixos-anywhere on it

if I can figure it out, though, would moving disko to use pkgs.nixosTest instead of make-test-python.nix as its entrypoint for NixOS vm-tests, and then modifying nixos-anywhere.sh to support running that test locally when it is used on macOS hosts be an agreeable change?