Unexpected full rebuild with small change

Help
1

Hi!

I’m building a nixos configuration. I’ve built it fully once, changed below lines of config:

+++ boot.kernelParams = [ "rw" ];
--- boot.kernelParams = [ ];

fileSystems."/" =
+++ { device = "/dev/disk/blabla";
--- { device = "/dev/disk/chacha";
    fsType = "f2fs";
  };

and to my surprise hit a rebuild equaly as big, taking in all of the dependencies once again:

❯ sudo nixos-install --root /run/media/zmrocze/barplus --flake .#barplus
[0/539 built, 16/4206/6300 copied (6208.3/15555.0 MiB), 1466.8/2034.5 MiB DL] fetching texlive-univierror

Why did this happen, should it happen and could we do better?

Of course the configuration changes with the above lines of config. But I don’t think any packages need to be rebuilt (I only guess that the config changes don’t influence any dependencies).
But as it looks many dependencies need to be fetched all over again. I don’t think anything gets built the second time - but just having to be refetched again while the configuration builts again is in itself most of the time spent builting it. Both times this took few minutes on my computer.

Did something went wrong? Is there more changes that I brought with the changed config lines? If not then still - Can we do better in terms of more gradual configuration build steps, more checkpoints - resulting in better caching?

Thanks!

3

Either you’re using a different nixpkgs revision somehow, or that --root argument is not pointing at the same place as you installed to before.

4

it’s possible that the drive was remounted,
but why would that matter?

5

Can you share your flake.nix and flake.lock?

6

of course,
thats the flake, though the change got swallowed by a single commit, its concerned with file nixos/barplus-hardware.nix.

I think there’s nothing special in the flake, instead I would suspect that the way configuration is calculated there’s no derivations created that would act as a cache checkpoint along the way, but instead it gets calculated as one big chunk. Does it make any sense?

7

Huh? That doesn’t sound like how this works, though I’m having trouble understanding your suspicion.

A NixOS configuration is just a derivation. Derivations share the parts they have in common. This isn’t a “cache checkpoint” problem. When you change your Nix expressions, you make a new NixOS config, but this new config shares everything that’s unchanged from the last config. It’s accomplished with cryptographic hashing, kind of like a merkle tree; not with some kind of cache invalidation strategy.

Just to make sure we’re on the same page… You’re using nixos-install --root /run/media/zmrocze/barplus because you’re installing to a different drive than you’ve booted, right?

8

Just to make sure we’re on the same page… You’re using nixos-install --root /run/media/zmrocze/barplus because you’re installing to a different drive than you’ve booted, right?

Yes