… while evaluating a branch condition
at /nix/store/7swmjsxz9m2gamk8q5m0m2byb2gq35v5-source/lib/modules.nix:295:9:
294| checkUnmatched =
295| if config._module.check && config._module.freeformType == null && merged.unmatchedDefns != [ ] then
| ^
296| let
(stack trace truncated; use '--show-trace' to show the full, detailed trace)
error: path '/nix/store/47gmghq44mdwmyfrl6pq2rfmnbsvzzrs-source/common/hardware-configuration.nix' does not exist
hardware-configuration.nix is missing in common as you have them in osytertop etc. I get this sometime changing things around where there seems to be some caching or not updating going on (sorry not sure the exact reason and hopefully someone else can chip in.
I find that nix-collect garbage --delete-older-than =7d or similar then rebuild works…
The nix store doesn’t come into play at eval time, this does nothing.
Garbage collection is not a troubleshooting step, even if there is store corruption the answer is a store repair rather than just random garbage collection. This is only necessary if you’re running out of disk space. Doing this in response evaluation errors (especially excluding things added in the last week) implies a fundamental misunderstanding of how nix works, please join me in my crusade against the cargo cult and stop recommending it.
Caching can come into play if you’re using flakes because flakes have an eval cache, but i’s highly unlikely that this is the issue here. It’s much more likely that your repository doesn’t contain the latest changes, please share your configuration as it is right now; push the state to a separate branch if you’re not ready to merge.
Can you show us a git diff? There are no references to that file in your repository, so it’s hard to go on your word here.
My best guess if there are indeed no changes is that you’re not running the code you think you are, what command are you running, and what is in $NIX_PATH?
git diff in the fifis_flakes git doesnt return nothing
I’m running “sudo nixos-rebuild switch --flake ~/flakes#thinkbug”
How to I print the $NIX_PATH to you ?
Thanks for the help
The change that ended up being made to it is at least that now you must specify a valid NixOS version, but I still think forcing it to be a hash would prevent mistakes like this… Anyway, this is besides the problem you’re having right now.
Hm, if you’re running that the contents of $NIX_PATH don’t actually matter, but a simple echo $NIX_PATH would do
You’re sure that directory contains the exact same repository as the commit you’ve just pushed? Again, there is no reference to that file:
And actually evaluating your configuration works just fine:
~/Documents/Projects/fifis_flakes> nixos-rebuild dry-build --flake .#thinkbug
building the system configuration...
warning: Git tree '/home/tlater/Documents/Projects/fifis_flakes' is dirty
these 385 derivations will be built:
/nix/store/00ggwi7kcxh7q83jlrma9p53b4rhc79a-check-link-targets.sh.drv
/nix/store/m0k29s59q5k2wawa3s4aj0d37hcb4d91-builder.pl.drv
...
I.e., if you were using the repository on codeberg, your configuration should evaluate just fine. You have either indeed stumbled upon a rather massive nix bug, or you’re not actually running the code you’ve published.
That does mean that if you ran nixos-rebuild without the --flake flag, it would read your configuration from /etc/nixos/configuration.nix. But as it stands, as long as you actually use the --flake flag, this should not be happening, so…
Give the last command I shared a shot, it’ll just use your codeberg code. If that works, we know for sure it’s something fishy with your local repos, and you should probably just restart from a fresh clone of your own repository.
