You are not logged in.
Login manager - SDDM
Window Manager - i3
Internet service - Network Manager
My wifi does not connect automatically to known networks on boot.
These are some relevant error logs from journalctl -
device (wlo1): no secrets: No agents were available for this request.
device (wlo1): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
manager: NetworkManager state is now DISCONNECTED
device (wlo1): Activation: failed for connection 'wifi_name'
state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')I feel that this may be because of a gnome-keyring and nm-applet order of execution conflict.
I made sure that gnome-keyring-daemon starts before nm-applet in my i3 config -
exec --no-startup-id gnome-keyring-daemon --start --components=pkcs11,secrets,ssh
exec --no-startup-id nm-appletThese are the contents of /etc/pam.d/sddm -
#%PAM-1.0
auth include system-login
-auth optional pam_gnome_keyring.so
-auth optional pam_kwallet5.so
account include system-login
password include system-login
-password optional pam_gnome_keyring.so use_authtok
session optional pam_keyinit.so force revoke
session include system-login
-session optional pam_gnome_keyring.so auto_start
-session optional pam_kwallet5.so auto_startThese are the contents of /etc/pam.d/ -
auth required pam_securetty.so
auth requisite pam_nologin.so
auth include system-local-login
auth optional pam_gnome_keyring.so
account include system-local-login
session include system-local-login
session optional pam_gnome_keyring.so auto_start
password include system-local-loginContents of .zshenv (I use zsh) -
if [ -n "$DESKTOP_SESSION" ];then
eval $(gnome-keyring-daemon --start)
export SSH_AUTH_SOCK
fiI followed the instructions here - https://wiki.archlinux.org/title/GNOME/ … _autostart about moving the files to a different folder and deleting the appropriate line.
The output of
nmcli connection show wifi_name | grep autoconnectis
connection.autoconnect: yes
connection.autoconnect-priority: 1
connection.autoconnect-retries: -1 (default)
connection.autoconnect-slaves: -1 (default)My /etc/hosts file is empty.
My hostname is the same as $USER.
The NetworkManager service is running.
This might be relevant - https://unix.stackexchange.com/question … -is-kept-i but I am not sure how to make the change suggested in the answer.
I would really appreciate any help with this.
Offline
Online
Yes, those settings are checked. It still doesn't work.
Offline
Please post a complete system journal (sudo journalctl -b), but if you store the passord w/ system availability (unencrypted) this will not be related to any gnome-keyring startup anymore.
Online
Please post a complete system journal
but if you store the passord w/ system availability (unencrypted) this will not be related to any gnome-keyring startup anymore.
Can you elaborate please?
Offline
Patching Network Manager as indicated here - https://unix.stackexchange.com/question … -is-kept-i and rebuilding from source worked.
Offline
Sorry, mised your last post.
From SE - you do understand the premise fro the requirement of that pactch?
By default the NetworkManager stores WiFi passwords in plain text in *.nmconnection files inside /etc/NetworkManager/system-connections/. This is not acceptable for me
so what he seems to end up doing is somehow creating a system wide activated connection that keeps failing until at some point his local keyring is available.
That's not required and completely insane.
The outcome is the exact same as having a regular-ass networkmanager setup w/ a connection privvy to your user that will be established when you login - but NOT on boot.
Online
The outcome is the exact same as having a regular-ass networkmanager setup w/ a connection privvy to your user that will be established when you login - but NOT on boot.
How would I go about doing this?
Offline
You configure a wifi connection w/ NM - it's the default behavior.
Check “Connect Automatically” but NOT “Available to all users”
Online
Tried that but did not work ![]()
Offline
Did not work "how"? Updated journal?
Your original journal has
Feb 10 09:39:18 reikdas NetworkManager[440]: <info> [1644503958.6437] device (wlo1): Activation: (wifi) access point 'PAL3.0' has security, but secrets are required.
…
Feb 10 09:39:18 reikdas NetworkManager[440]: <info> [1644503958.6462] device (wlo1): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
…
Feb 10 09:39:46 reikdas systemd-logind[442]: New session 2 of user reikdas.
…
Feb 10 09:39:46 reikdas sddm-helper[755]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
…
Feb 10 09:39:47 reikdas NetworkManager[440]: <info> [1644503987.0658] policy: auto-activating connection 'PAL3.0' (0441ea69-3a99-4359-a9d8-21e73675d61a)
…
Feb 10 09:39:47 reikdas NetworkManager[440]: <info> [1644503987.0737] device (wlo1): Activation: (wifi) access point 'PAL3.0' has security, but secrets are required.
…
Feb 10 09:39:47 reikdas gnome-keyring-daemon[767]: no private keys found in file
Feb 10 09:39:47 reikdas gnome-keyring-daemon[767]: invalid or unrecognized private SSH key: reikdas@reikdas
Feb 10 09:39:47 reikdas gnome-keyring-daemon[767]: Unsupported or unknown SSH key algorithm: ssh-ed25519
Feb 10 09:39:47 reikdas NetworkManager[440]: <warn> [1644503987.1289] device (wlo1): no secrets: No agents were available for this request.
Feb 10 09:39:47 reikdas NetworkManager[440]: <info> [1644503987.1290] device (wlo1): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
…
Feb 10 09:39:54 reikdas NetworkManager[440]: <info> [1644503994.1903] device (wlo1): Activation: (wifi) access point 'PAL3.0' has security, but secrets are required.
…
Feb 10 09:40:01 reikdas NetworkManager[440]: <info> [1644504001.0561] manager: NetworkManager state is now CONNECTED_GLOBALNM tries to connect to the AP and predictably fails at 09:39:18 because your keyring isn't available and the connection not shared.
You log in at 09:39:46, NM tries again at 09:39:47 but fails again as gnome-keyring isn't yet ready and ultimately succeeds at 09:39:54 and you've a working lease 5 seconds later.
This certainly doesn't meet the "at boot" criteria, but looks like "on login" was working before?
Online