Colmena - Public Room Timeline

	Colmena	332 Members
	A simple, stateless NixOS deployment tool - https://github.com/zhaofengli/colmena	117 Servers

Load older messages

Sender	Message	Time
24 Jun 2022
Linux Hackerman	Happens :D	11:09:32
hexa	❯ colmena build [INFO ] Using configuration: /home/hexa/git/hexa/nixos-servers/config/hive.nix [INFO ] Enumerating nodes... error: attribute 'type' missing at /nix/store/agbalx3d9vi1sd132w5qs4p6i3brya1f-nixos-22.05-src/lib/modules.nix:615:26: 614\| else if optionDecls != [] then 615\| if all (x: x.options.type.name == "submodule") optionDecls \| ^ 616\| # Raw options can only be merged into submodules. Merging into Did you mean _type? (use '--show-trace' to show detailed location information) [ERROR] ----- [ERROR] Operation failed with error: Child process exited with error code: 1	11:28:23
hexa	this is a fun one.	11:28:34
hexa	because nowhere in the trace there is a reference to the module in question	11:28:54
hexa	do people tend to write scripts around colmena for: apply boot reboot unlock upload secrets	13:15:17
hexa	with morph I could do `morph deploy default.nix boot --reboot --upload-secrets`	13:15:32
hexa	and colmena seems to upload secrets uploadAt=post-activation on applies with goal=boot directly after uploading the closure	13:16:39
hexa	which is quite pointless when the secrets are volatile	13:16:49
hexa	* and colmena seems to upload secrets with `uploadAt=post-activation` on applies with `goal=boot` directly after uploading the closure	13:17:07
hexa	ah, reboot handling is part of 0.4.0	13:22:30
hexa	In reply to @linus:schreibt.jetzt Just reconfigure then :D lol nope. can't reconfigure interfaces that don't exist, because of missing prerequisites	15:10:01
hexa	so restarting networkd it is	15:10:05
Zhaofeng Li	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 Yeah, the behavior of `uploadAt=post-activation` should probably be special-cased for `--reboot`	18:06:02
hexa	strictly speaking: activation happens at boot time for goal=boot	19:18:46
hexa	so don't upload secrets in that case unless --reboot is given	19:19:14
hexa	* so don't upload post-activiation secrets in that case unless --reboot is given	19:19:22
hexa	* so don't upload post-activiation secrets in that case unless --reboot is given and then post-reboot 😄	19:19:26
25 Jun 2022
Winter (she/her)	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?	16:55:50
Zhaofeng Li	Another person [encountered the same thing](https://matrix.to/#/!BgJZHVOYkwVcEKLAyM:nixos.org/$pYUmOSAIpDOIbLl4q2TMc-0iyKrimWZfnFQi4Fdm6RA?via=zhaofeng.li&via=matrix.org&via=matrix.eno.space) in the deployment channel. It's a bit weird that it worked before.	20:58:32
Zhaofeng Li	Is it possible that the original output was cached somehow?	20:58:55
Winter (she/her)	In reply to @zhaofeng:zhaofeng.li Is it possible that the original output was cached somehow? That was my thought too, but then I GC'd my store and can still reliably reproduce this.	21:47:06
Winter (she/her)	In reply to @zhaofeng:zhaofeng.li Is it possible that the original output was cached somehow? * That was my thought too.	21:47:39
Winter (she/her)	Do you have any clue how the working version could be evaluating just fine, though? I GC'd my store before evaluating and the same results happened (I could eval one but not the other.)	21:48:24
Winter (she/her)	Oh, I see the issue maybe.	21:53:21
Winter (she/her)	I run home-manager on the same system, which in the right sequence of events, would cache the needed `nmd` source.	21:53:45
Winter (she/her)	Hah.	21:53:49
Winter (she/her)	I think this is the reason why 😆	21:54:15
Winter (she/her)	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.	22:03:52
26 Jun 2022
Zhaofeng Li	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. It should fix the issue since the dependency flake is no longer fetched in a derivation	01:48:02
Winter (she/her)	In reply to @zhaofeng:zhaofeng.li It should fix the issue since the dependency flake is no longer fetched in a derivation Ah, flake-compat only uses builtins.	02:59:51

Show newer messages

Back to Room ListRoom Version: 6