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

Development
1

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 allowDecoupled = true.
  • Create a nix command that outputs all installed apps tagged as ‘decoupled’ for debugging purposes when something like this goes wrong.

I suspect this could be implemented similarly to allowUnfree.

10 Likes
2

Would stopping the Mullvad Daemon have brought network connectivity back?

3

It would have, but nixos-rebuild refused to rebuild without an internet connection, so I couldn’t stop it.

4

What I mean is that services.mullvad when enabled creates a systemd-service named mullvad-daemon. This daemon can be started and stopped during runtime. So I wonder if it was possible to get internet access back by running systemctl stop mullvad-daemon.

1 Like
5

I’m not sure what effect that would have had, but even if it works, it wasn’t obvious that mullvad created the problem.

I’d had services.mullvad enabled for several months, I’d changed nothing, and my network access just disappeared. So systemctl stop mullvad-daemon wasn’t an obvious thing to try.