Some implementation details of the NixOS network-interfaces module have been changed:
In the “scripted” backend (networking.useNetworkd = false, the default), network-setup.service has been removed and the network configuration services are now part of network.target, which is now directly pulled into multi-user.target. Consequently, interface addresses, routes and default gateways are configured asynchronously as soon as the underlying network devices become available (fixes issue #154737).
In both “networkd” and “scripted” backends, the configuration of name servers is now part of network-local-commands.service (fixes issue #445496).
The issue that resulted in a completely unconfigured network if both resolvconf was disabled and no default gateway configured, has also been fixed.
These shouldn’t be breaking changes, but if you relied on some of the internal details (like for custom netdevs, or ordered services after network-setup.service) then you may have to update your configuration.
promtail reached its end of life and will be dropped soon, as it is currently blocking the grafana-loki bump to 3.7.x:
Just like with the removal of grafana-agent a year prior, you can either migrate to grafana-alloy (which is what Grafana recommends), or, if you are looking for something more light-weight, fluent-bit.
post-resume.target has been removed. See {manpage}systemd.special(7) about sleep.target for instructions on ordering a process after resume with ExecStop=.
As part of the by-name migration for darwin, darwin.mkAppleDerivation has been removed from the darwin package set.
Since it only works for building the source releases packaged in Nixpkgs, it’s unlikely there are any external users, but the change is technically breaking.
Stage 1 (a.k.a. initrd) is now based on systemd by default, and the old scripted implementation is deprecated and scheduled for removal in 26.11. If you run into issues migrating, you can get help from the community or report an issue on GitHub.
You can temporarily revert to the scripted stage 1 implementation by disabling boot.initrd.systemd.enable, but this is discouraged.
Most incompatibilities will be explained with assertions during configuration evaluation, but be aware of the following that can’t be automatically detected:
If you use LUKS disk encryption, ensure that fileSystems."/".device is set to "/dev/mapper/<name>", where <name> matches the name in your boot.initrd.luks.devices.<name> definition, to avoid systemd timing out while prompting for a passphrase. If you have a more complex setup, e.g. with LVM on top of LUKS, you may need to add "x-systemd.device-timeout=infinity" to fileSystems."/".options instead. If you need to disable the timeout before you can boot into the system, pass systemd.default_device_timeout_sec=infinity on the kernel command line.
The cryptsetup-askpass program is not available; use systemctl default instead, which will prompt for passphrases as necessary. If you pipe password responses into SSH over stdin, use ssh -o RequestTTY=force to ensure systemctl default gets a TTY to prompt on.
Many kernel parameters have been replaced with native systemd versions; see the “Boot Problems” section in the manual when it updates.
Many third-party modules and tools have already been adapted for systemd stage 1, but some like nixos-infect will still require adjustment to be compatible
Whether you want to upgrade Dovecot to 2.4 or not, a lot of module options got renamed / removed because of this change so manual intervention may be required.
The source release sources are no longer tied to the SDK. They have been moved into the darwin package set. The apple-sdk.sourceRelease function is now an alias for darwin.sourceRelease and will be removed in a later release. Separating the source releases will allow the SDK to be updated more quickly (hopefully as soon as it is released).
Note: Different versions of the source releases are no longer available via the SDK. The only versions are those packaged in the darwin package set. They are currently a mix of 14.4, 15.4, and 15.6 source releases. I will be updating them shortly to 26.3.
To go along with my nodePackages removal from a few months ago, mkYarnPackage has been removed from nixpkgs, along with yarn2nix(and yarn2nix-moretea), along with its documentation. If you are still using yarn V1 instead of yarn-berry, use the yarn build hooks (https://nixos.org/manual/nixpkgs/stable/#javascript-yarn-v1) instead, as they are a more modern and lightweight way of building yarn-based packages.
I wanted to share a heads-up in case it helps others avoid the same issue.
I recently tried upgrading a NixOS machine running on an AWS EC2 t2 instance from NixOS 25.11 to nixos-unstable (or newer stable version when it will come out), and the machine no longer boot correctly afterwards (kernel panic, etc etc).
The affected instance was a t2 instance, which is Xen-based. In my case, the practical solution was to migrate the machine to a t3 instance, which is Nitro-based.
This may be related to the differences between older Xen-based EC2 instances and newer Nitro-based instances. I have not investigated the root cause deeply enough to say whether this is a NixOS regression, an AWS-specific compatibility issue, or simply an unsupported/fragile upgrade path.
Still, it may be worth documenting somewhere that upgrading older EC2 t2 instances to nixos-unstable can be problematic, and that moving to a Nitro-based instance type such as t3 appears to solve the issue.
Hope this saves someone else a bit of debugging time, and thanks @arianvp for finding the solution !
Don’t know if I missed it but there seems to be a breaking change for opencloud when upgrading from 6.x to 7.0 because of missing values in the configuration.
Polkit’s pkexec setuid root wrapper will become opt-in with
The reason is that I want to focus my systems on systemd’s run0, which requires polkit, but at the same time slowly walk away from tools like sudo, sudo-rs or doas.
Did you know:
Instead of sudo -i you can just call run0 to elevate to root.
Enable security.run0.enable today*!
*) after this PR reaches your system closure
We did most of the work to find consumers of polkit, which also call pkexec and enabled security.polkit.enablePkexecWrapper for those. The intent to merge is late this week or early next week, as we expect nothing about this change to be controversial.
Honorable mention for run0-sudo-shim if you want to keep a sudo compat layer.
I ditched sudo for run0 a while ago now¹, but I didn’t have to enable anything explicitly. Will we now need to enable run0 explicitly, and, if so, will there be an eval warning? I don’t want to update only to discover that my superuser access doesn’t work anymore, but I’m not sure how the warning would work if I didn’t have to make any specific changes previously that would indicate a warning of a change in behaviour is necessary.
¹Several months ago at least; jj resigned all my commits so unfortunately I can’t tell exactly when.
Run0 requires polkit for elevation. If you have that incidentally right now the module allows for declaring that dependency explicitly. Run0 is in the weird spot, that it ships by default with systemd, but polkit remains opt-in for good reasons.