Just wanted to bring up that the change to default true for boot.initrd.systemd.enable was surprising for me, in kind of a weird way.
I have been running systemd bootloader for as long as I’ve had this system, but a few months ago added an initrd unit to rollback one of my btrfs subvols on every boot. What I didn’t realize was that this unit was actually not running because systemd initrd defaulted to disabled.
When I updated to 26.05, this unit started running and rolled back the subvol. Apparently I had been unexpectedly relying on data that was accidentally getting persisted here.
This wasn’t a big deal, no crucial data, just surprising. Not sure if anything should change here, maybe an eval warning when systemd initrd units are defined with systemd not handling initrd, but erroring on disabled module config feels dirty. The other thing may be gating this default change behind stateVersion with a warning.
3 Likes
That’s probably too late at this point; the default is now the systemd initrd, and the non-systemd initrd is about to be deprecated. If you were making this mistake, you have already stumbled on it, the warning lacks a trigger condition since the initrd is handled by systemd the moment you upgrade, and new users cannot make it anymore (unless they explicitly choose to use the deprecated non-systemd initrd on a new system, which would be weird).
I really don’t think stateVersion would be appropriate here. The upstream modules don’t touch any state, you can’t tie every change behind stateVersion just because a user might write something like if [ -e /bin/firefox ]; rm -rf /; fi into a systemd unit.
I don’t think in this case it would have helped to hide this behind stateVersion, either, that just forces upstream to maintain the scripted initrd forever, or delays the issue (even with a warning, that’s not much different from an entry in the release notes).
Given the entire point is getting rid of the maintenance burden of a hand-rolled init setup, I think this kind of “solution” of delaying the inevitable as much as possible would be unworkable.
I do think adding a warning one release in advance would be less of a rug-pull for users who don’t read the release notes, but the edge cases that were at all foreseeable have assertions, so you have to do pretty bespoke things to run into issues. And, well, it would not have helped you, you clearly did read the notes.
It’s an unfortunate situation, but well, it’s worth checking if systemd units you wrote actually run from time to time.
1 Like
Thanks for the pointer to that thread! I’m still early in my journey to NixOS operational stricture.