In reply to @linus:schreibt.jetzt
Just reconfigure then :D

In reply to @hexa:lossy.network
and colmena seems to upload secrets with uploadAt=post-activation on applies with goal=boot directly after uploading the closure

So I'm trying to debug a weird issue.

home-manager revisions, for at least a few months now(???), have failed to build their nmd fetcher derivation when building for x86_64-linux with Colmena's build on target feature, when the system != x86_64-linux. The derivation in question is defined here.

HM commit e66f0ff69a6c0698b35034b842c4b68814440778 suddenly fixes the fetching of this derivation, by merely changing the commit hash. The diff between the failing and the succeeding derivations is just as you'd expect: just the hashes and revisions change, nothing else.

The error that's occurring with these faulty revisions are error: a 'x86_64-linux' with features {} is required to build '/nix/store/7fhf5jvnmz8wpy38v44j5cfn7mgxg7kj-nmd.drv', but I am a 'aarch64-darwin' with features {benchmark, big-parallel, nixos-test} (7f... is failing in the diff). They both have system = x86_64-linux in the derivation, so what's going on?

In reply to @zhaofeng:zhaofeng.li
Is it possible that the original output was cached somehow?

In reply to @zhaofeng:zhaofeng.li
Is it possible that the original output was cached somehow?

https://github.com/nix-community/home-manager/commit/64ab7d6e8d157848ec285cd267db29e2f14c1076 switched HM to use a flake input for nmd, but it uses flake-compat to actually import it in docs/default.nix

I think this will still cause the same issue, since it really didn't change anything (as in, it still does IFD)? Correct me if I'm wrong.

In reply to @winterqt:nixos.dev

https://github.com/nix-community/home-manager/commit/64ab7d6e8d157848ec285cd267db29e2f14c1076 switched HM to use a flake input for nmd, but it uses flake-compat to actually import it in docs/default.nix

I think this will still cause the same issue, since it really didn't change anything (as in, it still does IFD)? Correct me if I'm wrong.

In reply to @zhaofeng:zhaofeng.li
It should fix the issue since the dependency flake is no longer fetched in a derivation

In reply to @huyage:matrix.org
I had no idea people use Nix for this. I used to do PXE boot. But now most IaaS bundle those 2 things together. For example, you ask for (provision) an EC2 instance running an AMI image (bootstrap). Is your use case like a local bare metal setup?

dantefromhell: Me too, I've been hacking on solutions for a while. My primary provider is hetzner (both cloud and bare-metal) and my general approach was to write a small script which collects info like hostname, available disks, network config, etc from a rescue system, then uses kexec to switch into a "live" nixos system while passing the collected info via kernel commandline and then partitioning and installing nixos from there on as normal.

My first implementation is available at https://github.com/dep-sys/nixos-zfs-installer but ended up with huge kexec images, so after learning more about nix(os) and looking into not-os in between, I restarted with https://github.com/dep-sys/nix-dabei.

That's not finished yet, but works for me and the general approach should be pretty portable between providers. Also because it should be rather trivial to build an iso or efi executable for the same expression used for kexec. same for netboot, but i haven't looked into that yet

In reply to @dantefromhell:matrix.org
Your approach to `nix-dabei` seems fairly similar to what I pondered a minimal `netboot` could look like 🤔

What would it take to get the zfs & raspberry features working (not necessarily both at the same time)? Those are hard requirements for a good solution in my environment