Apps that make system changes you can't roll back should be opt-in only (like `allowUnfree`)

Recently, an update to mullvad-vpn wiped out all my network access (wifi, ethernet, bluetooth, everything). This would have been fine, except

  • booting into an older system build didn’t fix the problem,
  • i couldn’t rebuild without network access (eventually i figured out how to boot into rescue mode), and
  • mullvad broke silently, so I had to gradually uncomment my entire system build to diagnose the issue.

I’m not the only person who was affected:

Note that the issues were opened from January–May, suggesting the timing with which this breakage hit users was somewhat random. Perhaps this is because the package updated independently of nixos system builds, but in any case, it was definitely making system changes that weren’t tracked by nix.

I don’t mind including packages that make non-rollbackable system changes in nixos—I use dropboxd, which auto-updates, and it’s great. However, I also strongly agree with these github comments:

Whats funny is that I thought NixOS was supposed to be reproducible so rolling back to a previous build in GRUB should fix the issue but not in this case. I had to reinstall NixOS and then everything worked.

This issue actually ruined my day. I think this should be very high priority because, agreeing with GersiD, NixOS’s whole thing is reproducibility. Very scary issue to run into.

Proposed solutions:

  • Require users to explicitly opt-in to these packages in their nix config with a flag like allowBuildDecoupled = true.
  • Create a nix command that outputs all installed apps tagged as ‘build decoupled’ for debugging purposes when something like this goes wrong.

I suspect this could be implemented similarly to allowUnfree.

4 Likes