I have laptop lenovo T490 which is working marvellous with fedora SB 41.
I would like to make sure that it always starts in airplane mode and if one needs wifi then airplane mode should be manually turned off.
What I currently experience is the opposite: box starts with airplane mode off and even if I turn it on, next reboot is off again.
are you suggesting that this should be Fedoraās default, or are you asking for how to make this the default on your system?
because if you want this for your system, then I think I know how to do that, at least it works for me.
anyway, the solution.
Iām using a laptop as well, and I donāt know whether everything Iām about to say will be the same on your laptop. But on my laptop, I figured out that the thing preventing default airplane mode is not wifi, but rather bluetooth. I found out that, for some reason, the bluetooth service is always on by default, even when you donāt activate it in the control center. You can check whether yours is on or not with systemctl status bluetooth (it might send you into a several page mode, where you might be confused by not seeing a new terminal prompt to type into - if that happens, you can just open a new terminal tab and use that, or close and reopen the terminal).
if your bluetooth is on, and you want it to always be off by default, then:
- run
systemctl disable --now --no-reload bluetooth, which will ask for your root password - in the output, it will probably ask you to run some other command - do that too.
- after that, if you check your bluetooth status again with
systemctl status bluetooth, it will probably be on again - I donāt know why that happens, so just runsystemctl disable --now --no-reload bluetoothagain. This time it should work and not ask you to run the second command. - check whether it worked by running
systemctl status bluetoothagain. Now the only green thing in the output should be āpreset: enabledā. Thatās fine, donāt mind it. I have it the same way, yet my system always has the bluetooth service off by default.
doing this should automatically enable airplane mode (unless youāre connected to a wifi, obviously), and it should also be off after restarting your machine. Thatās how it is for me, anyway. If something didnāt work for you, or you have questions, let me know and we can try to look at it.
now, I have never checked whether using the bluetooth button in the control center works after doing all of this. If you ever need to use bluetooth, and that button doesnāt work, then you can run systemctl enable --now bluetooth (for one time usage). If you want to have the bluetooth service always be enabled by default, then you can run systemctl enable --now --no-reload bluetooth.
about wifi - my system remembers whether I had it on or off when I shutdown my computer, and next time it starts with the same state. I suppose it should be the same on your system too.
2 Likes
This makes a lot of sense since bluetooth is also radio which is disabled by airplane mode. Airplane mode shuts off both wifi and bluetooth.
Thanks @blind-confused for helping.
I had partial success: following ^^ I now get wifi+bluetooth persistently disabled, but still airplane mode is disabled after reboot. See attachment.
I think that you can consider that full success.
Airplane mode turns off both wifi and bluetooth (turns off all radios) and even though the indication is not that airplane mode is enabled, the result is the same. The only real difference I see is the indication in that popup panel.
hmmā¦ just to make sure, can you try this (while wifi is disabled) and post the outputs?
nmcli radio wifi
sudo rfkill list
ip link show (I donāt think this one actually shows your IP, but Iām not 100% sure; if you donāt wanna risk it, you can skip it)
It does not show the IP but does show the current MAC.
lera@T490:~$ nmcli radio wifi
disabled
lera@T490:~$ sudo rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
Soft blocked: no
Hard blocked: no
1: tpacpi_wwan_sw: Wireless WAN
Soft blocked: no
Hard blocked: no
2: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
lera@T490:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wwan0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/none
3: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:2b:67:0c:fb:ea brd ff:ff:ff:ff:ff:ff
4: wlp0s20f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 2a:25:77:04:03:24 brd ff:ff:ff:ff:ff:ff permaddr 58:96:1d:ba:f1:c6
lera@T490:~$
Technically Yes, but I would have a hard time to explain it to the flight attendant 
weird, on my computer sudo rfkill list shows that everything is soft(software) blocked, but on yours nothing is. Not sure what thatās aboutā¦
and this is where my āexpertiseā sort of runs out too haha, Iām not a very technical userā¦ I was thinking the method that worked for me would work for you too, but perhaps someone else knows what to do?..
if no better solution is found, perhaps you could enable airplane mode, then enable sleep mode (suspend mode) and just use that instead of actually shutting down your laptop.
I mean, you should check right now, whether airplane mode is still on after waking the laptop up.
Could also maybe opt to disable Wifi in BIOS. I dock my laptop most of the time and have the whole wifi card disabled in BIOS so it isnāt taking up resources doing nothing.
I started experimenting with a couple kernel parameters
rfkill.default_state=0 systemd.restore_state=0
1 Like
hmm
seems gnome may be usurping rfkill from the kernel
I see the files in /var/lib/systemd/rfkill getting updated as I controll airplane mode from gnome.
So I turned wifi and bluetooth off which results in gnome reporting the system being in airplane mode then
grep . /var/lib/systemd/rfkill/*
all were set to ā1ā
chattr +i /var/lib/systemd/rfkill/*
reboot
but it did not work.
systemctl --user cat org.gnome.SettingsDaemon.Rfkill.service
seems to be what gnome does. So far I have not found any state it keeps though.
2 Likes
I have a setup that works for me.
The installation I am testing on is gnome but not workstation, rather fedora-release-identity-basic-40 a-la-cart.
First I added a couple kernel parameters
rfkill.default_state=0 systemd.restore_state=0
Then I turned on each device with a radio then turned them off to make sure files were populated in /var/lib/systemd/rfkill/. To verify all was off check that each files contains ā1ā
grep . /var/lib/systemd/rfkill/*
And to make this the default on every boot make the files immutable
chattr +i /var/lib/systemd/rfkill/*
Next was getting NetworkManager to have saved state with all radio devices off
nmcli radio all off
And to make that immutible
chattr +i /var/lib/NetworkManager/NetworkManager.state
.
.
So far so good but mine is just one scenario.
Making files immutable is not a great solution. It would be nice if mandatory dconf keys could be used at the system level yet still allow temporary enablement during each userās session.
1 Like
Unfortunately, still doesnt work: when I reboot, airplane mode is lost.
But I noticed something weird, maybe this is the culprit.
There are more rfkill file related to bluetooth and the first two are always=0 even when I manually set airplane mode:
T490:~$ grep . /var/lib/systemd/rfkill/*
/var/lib/systemd/rfkill/pci-0000:00:14.0:bluetooth:0
/var/lib/systemd/rfkill/pci-0000:00:14.0-usb-0:10:1.0:bluetooth:0
/var/lib/systemd/rfkill/pci-0000:00:14.3:wlan:1
/var/lib/systemd/rfkill/platform-thinkpad_acpi:bluetooth:1
/var/lib/systemd/rfkill/platform-thinkpad_acpi:wwan:1
After dnf update brought in a new systemd update the immutable attributes were lost. So I had to reapply the immutable attribute after turning off all the radios again. I am not sure if gnome, NetworkManager, systemd or kernel need modification to support airplane mode as default. I did see a relavant gnome issue on the topic. They probably all need to be adjusted simultaneously.
Even though this solution is a pain to keep up it is very nice to have.
I tried this today and it appeared to work for gdm and for the normal users.
Made a desktop file to run rfkillā¦ called it rfkill.desktop
[Desktop Entry]
Type=Application
Name=rfkill block all
Exec=/usr/sbin/rfkill block all
NoDisplay=true
copied the desktop file to:
/etc/xdg/autostart/
/usr/share/gdm/greeter/autostart
sudo cp rfkill.desktop /etc/xdg/autostart/
sudo cp rfkill.desktop /usr/share/gdm/greeter/autostart
Unsure if it will stick through an updateā¦
1 Like
Just have to be willing to accept the short time window where the radios may be active before they are rfkillāed. I have worked in environments where this is not acceptable and will be detected.
The method I described is not without shortcomings. If I change the hardware (add a device, remove a device) I have to manually update the configuration.
Are you able to verify that the method I described is actually making it such that the radios never have a chance to become active until the logged in user activates them? This seems so from how I read the documentation. I am putting the immutable attribute on the directory as well to see if it survives updates.
chattr +i /var/lib/systemd/rfkill
1 Like
Fair point.
It does based on looking at the logs and rebooting a few times this evening.
it is a shame that something like this can not be set easily and system wide.
I guess it keeps us on our toes.
Thanks