Airplane Mode (radios) not persistent between reboots

When turning off Airplane Mode (radios) during a Gnome session, it turns back on after reboot. The default, the system reverts to seems to be on.

Under Debian a similar behaviour is observed. Under Arch (EndeavorOS), the Airplane Mode setting is persistent.

How to either make it persist or change the default to off (edit)?

This worked for me:

{
  # Enables systemd-rfkill.service
  boot.kernelParams = [ "systemd.restore_state=1" ];
}
1 Like

Hi,

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.

1 Like

does not work for me. I guess, it should restore the previous session status but instead the hardware status seems to be restored.

well explained but I am bit a lost. Would you proposing any lines to add to configuration.nix?

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”.

1 Like

Are you using impermanence? If so you would need to persist the systemd state.

1 Like

I noticed, too. Good remark.

I figured this: Airplane Mode (my MSI BIOS does not have an option for it) seems to be only the product of both WiFi and Bluebooth OFF. Toggling Airplane Mode seems not to work reliable and often not persistent between boots. However, if both WiFi and Bluebooth 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.

That hypothesis does not hold any more for another (MSI) Laptop. I now have to investigate all hints from @rvl

Hopefully, future Linux releases will have a user friendly solution for the problem.