autoUpgrade seems not working

Help
1 
  system.autoUpgrade = {
  enable = true;
  # add the --upgrade-all flag
  flags = [ 
    "--upgrade-all" 
  ];
  allowReboot = true;
  };

seems not working. Instead:

sudo nix-channel --update
sudo nixos-rebuild switch

needs to be run manually to keep NixOS up-to-date. Any advice?

N.B. Automatic upgrade seemingly not working is unrelated.

2

Can you show logs from the relevant unit?

3

Sure. Any recommendations on how best to create a log?

4

The auto upgrade module creates a systemd service “nixos-upgrade”, so you can get the logs for that service through journalctl.

3 Likes
5 
Jul 12 08:33:52 nixos nixos-upgrade-start[3135]: building '/nix/store/krv3d6v1qi1v6kcx0abjm3mzfhsx57mz-nixos-system-nixos-26.05.4659.8f>
Jul 12 08:33:53 nixos nixos-upgrade-start[10794]: Not checking switch inhibitors (action = boot)
Jul 12 08:33:53 nixos nixos-upgrade-start[1912]: Done. The new configuration is /nix/store/g3zs90mdshjsy17bq50knxflki26an85-nixos-syste>
Jul 12 08:33:53 nixos nixos-upgrade-start[10825]: unpacking 2 channels...
Jul 12 08:33:53 nixos nixos-upgrade-start[10860]: unpacking 2 channels...
Jul 12 08:33:54 nixos nixos-upgrade-start[10824]: building the system configuration...
Jul 12 08:34:01 nixos nixos-upgrade-start[11038]: Checking switch inhibitors... done
Jul 12 08:34:02 nixos nixos-upgrade-start[10824]: Done. The new configuration is /nix/store/g3zs90mdshjsy17bq50knxflki26an85-nixos-syst>
Jul 12 08:34:02 nixos systemd[1]: nixos-upgrade.service: Deactivated successfully.
Jul 12 08:34:02 nixos systemd[1]: Finished NixOS Upgrade.
Jul 12 08:34:02 nixos systemd[1]: nixos-upgrade.service: Consumed 3min 16.790s CPU time over 3min 23.683s wall clock time, 4.5G memory >

seems to have worked. Why is the service termed “upgrade”? It seems to be rather an update depending on its definition.

6

Because the terms “upgrade” and “update” are used interchangeably in common English, and NixOS has no glossary, standardized review practices, or coherent vision. We can’t even consistently document our modules, are you really expecting consistent use of semi-technical terms?

The --upgrade-all flag also is also out of line.

That said, because of this ambiguity, it’s hard to tell why you are disappointed by its behavior. Were you expecting an automatic upgrade to 26.05 (which really shouldn’t exist), or do you have yet another definition of “upgrade”?

2 Likes
7

To my understanding a “system upgrade” should be tied to the bi-annual version number update as opposed to a “system update” that deals with anything in between. I also have an Arch Linux system seeing at least daily updates.

I am worried not to automatically receive “system updates” in that sense, say on a weekly or even daily basis. The log from nixos-upgrade indicates that the service works - I just have not seen it rebooting and have become suspicious. Then, running the above command supdated my system big time.

I agree that such discussions are quite important to conduct.

1 Like
8

I am confused that you haven’t set either channel nor flake here. This should actually fail evaluation.

Edit: forget this, I misread the assertions.

9

There will never be a service in NixOS that automatically upgrades to the new stable, and this is intentional. You need to handle the data and settings changes that will be affected by the breaking changes, because that is outside the scope of NixOS.

If you want to upgrade to the new stable, you have to make the necessary changes to your config, migrate your data, then change your channel or flake input or whatever and then let it do its thing.

2 Likes
10

If you need to leave a system unattended for a year or even more, NixOS likely isn’t for you. There are LTS alternatives available, like CTRL-OS (to which I have no affiliation, it’s just the only one coming to my mind right now).

2 Likes
11

Ok, then yeah, the autoUpgrade service indeed performs automatic updates, not upgrades, by your definition.

The naming is indeed silly, but entirely un-sarcastically, I don’t think you can expect the kind of polish you’d need to get consistent naming from NixOS. We just don’t have the functioning organizational structure that’d be needed to enforce that kind of thing, unlike the big distros like Debian or Fedora. Too few experienced people, too big of a scope. Hell, even those distros struggle from time to time.

You can try sending up PRs with deprecations for this and other inappropriately named update things, they might be accepted.

If you care about these kind of details in general, I suggest manually looking through the NixOS modules you use. Maybe upstream fixes where you see problems, we could use your hands and eyes.

Is that the first time the service ran or do you have longer-term logs?

The allowReboot option is documented as follows (emphasis mine):

Reboot the system into the new generation instead of a switch if the new generation uses a different kernel, kernel modules or initrd than the booted system.

Kernel updates aren’t that common, and you probably haven’t made un-applied system changes. If your system isn’t all that old, there’s a good chance you simply haven’t seen a kernel update.

If you want to assert that auto reboots happen experimentally, you can try to add a random kernel module to your config and start the service manually with systemctl start.

2 Likes
12

Speaking about it, I have just had it auto-reboot on another Laptop. I will have more time on my hands next year, get into NixOS deeper and support it.