system.autoUpgrade fails, "unrecognised flag"

Hi, I am trying configure automatic upgrades. My config is

system.autoUpgrade = {
enable = true;
flags = [
"-L"
];
dates = "10:22";
randomizedDelaySec = "45min";
allowReboot = true; # Set to true if you want automatic reboots
};
in configuration.nix.

But the result is this:

an 31 10:28:46 nixos systemd[1]: Starting NixOS Upgrade...
Jan 31 10:28:49 nixos nixos-upgrade-start[11037]: unpacking 1 channels...
Jan 31 10:28:54 nixos nixos-upgrade-start[11095]: error: unrecognised flag '--print-build-logs'
Jan 31 10:28:54 nixos nixos-upgrade-start[11095]: Try 'nix-build --help' for more information.
Jan 31 10:28:54 nixos nixos-upgrade-start[11036]: Command 'nix-build '<nixpkgs/nixos>' --attr config.system.build.nixos-rebuild --print-build-logs --no-build-output --no-out-link' returned non-zero exit status 1.
Jan 31 10:28:54 nixos systemd[1]: nixos-upgrade.service: Main process exited, code=exited, status=1/FAILURE
Jan 31 10:28:54 nixos systemd[1]: nixos-upgrade.service: Failed with result 'exit-code'.
Jan 31 10:28:54 nixos systemd[1]: Failed to start NixOS Upgrade.

I did this based on this article: Automatic system upgrades - Official NixOS Wiki

My channel is nixos-25.11-small.

I tried both -L and --print-build-logs as flags, but same result. Does anyone have an idea what is wrong?

Thanks :slight_smile:

-L does not work with nix-build, it’s a flag for nix3 commands (generally used with flakes). Just remove the flag, nix-build already prints logs by default. See manual: nix-build - Nix 2.33.1 Reference Manual

Unrelated: you should probably not use the -small variant.

Thank you, that worked.

I am using nixos as a headless server, that’s why I thought the small variant is suitable here. Any reasons not to use the small variant in this case?

People tend to think -small means that the resulting disk size or memory footprint is small. This is not the case; the result is exactly the same as with the normal channel.

The channel dictates update schedule, the configuration dictates package contents.

Instead of affecting disk space, the -small channels get updated a little faster; the channel moves ahead as soon as a very small number of “essential” packages is built and cached.

The result is that you get updates sooner (by a few hours to up to about a day), which is quite useful if you want to patch critical CVEs as soon as humanly possible; however, the trade-off is that you might need to build certain packages locally instead of benefitting from the cache.

So, depending on which packages you use in practice, the automated rebuild might end up periodically putting your server to the task of building a huge tree of packages.

Typically a server is sized to do more or less exactly what it should, so these random rebuilds will have an immensely negative effect on the performance of whatever the server’s actual task is.

Ergo, when doing automatic updates, you should probably not use the -small channels.


I think they make more sense for one-off deployments when you want to fix a specific CVE that’s caught in the pipeline.

That, or if you know that all the software you need is covered by the -small channel; unfortunately the selection criteria are pretty arbitrary at the moment, so this is a hard requirement to meet.

Or maybe if you have a separate build server that you can submit the builds to; that’d mean a different config from what you have though and be a bit more bespoke.

1 Like

Thanks for the explanation, I wasn’t aware of that. Well, still a lot to learn here, but I’ll take my time.

Luckily the updates have gone smooth so far. But I’ll probably switch channel.