This usually happens because NetworkManager and rfkill restore the hardware radio state at boot, which can override your previous session settings. On NixOS, you can make the Airplane Mode state persistent by explicitly configuring NetworkManager and rfkill behavior in your system configuration.
You may also find it helpful to check how persistent state handling is done in other system workflows like srd cancel processes, where state changes must be saved and restored correctly across sessions. The same principle applies here, ensuring system state persistence across reboots.
Hopefully, this helps point you in the right direction.
Perhaps to achieve persistency between reboots is more difficult than simply overwriting the hardware system status with “radios off“ after boot. This is my desired state, see edit above.
Any specific recommendations how to easily turn “radios off“ in configuration.nix?
The above post by Ayana doesn’t make any sense and seems to be SEO spam.
I don’t understand the difference between session status and hardware status. My source of truth is the output of rfkill:
root@blue:~ # rfkill
ID TYPE DEVICE SOFT HARD
0 wlan phy0 blocked unblocked
You could also run nmcli radio to see NetworkManager’s view of airplane mode.
Sorry, my first answer probably needed more explanation. What it does is enable systemd-rfkill.service.
This worked for me on a NixOS system running GNOME and NetworkManager. I can see the rfkill state stored in /var/lib/systemd/rfkill/pci-0000:06:00.0:wlan.
If systemd-rfkill doesn’t work for you, check the service status and the contents of /var/lib/systemd/rfkill.
It would probably take two reboots for this config to take effect. One reboot for the kernel boot option, and another reboot to save the rfkill state to disk.
If you want airplane mode at startup always, some BIOS have an option for that (my laptop BIOS does). There is also a systemd oneshot service solution available if you search this forum for “rfkill”.
I figured this: Airplane Mode (my MSI BIOS does not have an option for it) seems to be only the product of both WiFiandBlueboothOFF. Toggling Airplane Mode seems not to work reliable and often not persistent between boots. However, if both WiFiandBluebooth are turned of manually (Airplane Mode is the result), then both of these settings (and thus Airplane Mode) are persistent.
In a nutshell: not relying on the Airplane Mode toggle but instead on the WiFi and Bluetooth ones solved my problem.
In addition boot.kernelParams = [ “systemd.restore_state=1” ];seems to be a default and therefore has no effect.