Wow ! Will do for sure
Thanks for digging it out !!
As they say the best way to find is knowing how to search (Sherlock Holmes)
p.s. theirs seems to be under Fedora. So their way to a solution may be a bit different. Just saying.
W
1 Like
NEWS
After trying a few other things, last night I did this:
sudo mv /usr/lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm.zst /usr/lib/firmware/iwlwifi-ty-a0-gf-a0.bak
As it was proposed here above and which I found on bugzilla.kernel.org/, where it was said: ''After upgrading linux-firmware lib,.... always have to use this command sudo mv /usr/lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm /usr/lib/firmware/iwlwifi-ty-a0-gf-a0.bak (networking - Intel Wifi 6 AX210 - WiFi not working after Update - Ask Ubuntu), and after this command, Wi-Fi module works.''
When firing up the laptop minutes ago, I am back to normal, like if the week-end being just a bad dream.
I'll come back here if the solution doesn't persist (i.e. if the issue comes back)
And all my thanks to Pavlos and Ric, you pointed me in the right direction... for the amateur that I am.
p.s. Some notes on forum say that that periodic updates to the package linux-firmware will install a new version of the offending file iwlwifi-ty-a0-gf-a0.pnvm and so this process (as above) may need to be repeated - until they solve it at Kernel level.
W
1 Like
False joy..... about 20 minutes into the wifi connection it failed. I am back into tethering now.
So it is a sign that it is not only a start-up issue.
A real time out issue - meaning that something is unstable
I may revert back to 24.04 LTS or find a way to install a previous Kernel.
Lets see
W
By the way, someone here knows how to 'reverse'/cancel such .bak after the fact ?
Hi,
As I understand, wi-fi stops working after suspend and iwlwifi is the driver which was working before suspending. Can you try this:
- before Suspend, do the following command
sudo modprobe –rv iwlwifi
- and after Suspend
sudo modprobe iwlwifi
''sudo modprobe –rv iwlwifi''
modprobe: FATAL: Module –rv not found in directory /lib/modules/6.11.0-9-generic
rv ?? just '' r '' would remove the iwlwifi module... right ?
Yes, it's correct. It will remove iwlwifi module and after suspending just run
sudo modprobe iwlwifi
1 Like
I will try
Amazingly, I am now connected to wifi (did a complete shut down before going out for a meeting). When back and with a fresh start, it connected... (!!!). Lets see if it fails this time around.
I've also made all 'suspend' off in power management.
But what you suggest would essentially refresh all the iwlwifi module. Right ?
W
It’s good that this working.
I had similar wi-fi problem on one of my laptops with UM 20.04 and Broadcom driver. Wi-fi was working after restarting of the system but stopped working after suspending.
Removing of iwlwifi module before suspending and loading it again after suspending, you can make automatic:
- Create a file (in terminal) :
sudo nano /lib/systemd/system-sleep/resume_iwlwifi.sh
Remark: This path is for UM 20.04 and I hope that this path is valid for UM 24.10.
- Just copy and insert the following script in to this file:
#!/bin/sh
case $1 in
pre)
modprobe -r iwlwifi
;;
post)
modprobe iwlwifi
;;
esac
-
To save file in NANO: Ctrl+O
-
To exit from NANO: Ctrl+X
-
Make the file executable:
sudo chmod +x /lib/systemd/system-sleep/resume_iwlwifi.sh
Also, it is possible to open properties of the file as superuser in Caja and change Permission - Execute - Allow executing as program
- Restart
2 Likes
Snowdog
If I do : sudo modprobe –r iwlwifi
I get: modprobe: FATAL: Module –r not found in directory /lib/modules/6.11.0-9-generic
lsmod | grep iwlwifi:
iwlwifi 684032 1 iwlmvm
cfg80211 1335296 3 iwlmvm,iwlwifi,mac80211
iwlwifi_compat 12288 4 iwlmvm,iwlwifi,mac80211,cfg80211
W
sudo modprobe –r iwlwifi
You have an en-dash (U+2013) instead of a hyphen (U+2D).
3 Likes
Duh!
I copied into a note and while typing my system made it a dash.....
Didn't notice and then copied to terminal 
As they say, half the problem is sometime right in front (18 inches) of the keyboard...
I made the correction and it did work
Thanks
W
1 Like
Hi guys
I was good for 2 days and the problem reappeared this morning. I did no suspend; merely shutdown and restart (2 or 3 times over the last 2 days)
If I do 'nmcli general status' I get:
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN METERED
disconnected unknown missing enabled missing enabled unknown
If I do 'sudo modprobe -r iwlwifi' I get:
rmmod: ERROR: Module iwlwifi is not currently loaded
modprobe: FATAL: Error running remove command for iwlwifi
W
P.S. A minute ago (i.e. after having written the above) I decided to reboot with the live USB plugged in - I thought that accessing the firmware via the USB may provide for some result. But I logged into the installed (not the USB) and wifi connection is active and iwlwifi module present/connected !!
nmcli general status
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN METERED
connected full enabled enabled missing enabled no (guessed)
What gives ? I am still confused as to what may happen ''behind the scene''...... Will tell you if connection persist once I will reboot without the USB...
Update
Minutes ago the connection dropped by itself.
I did:
sudo systemctl restart NetworkManager
I got:
Warning: The unit file, source configuration file or drop-ins of NetworkManager.service changed on disk. Run 'systemctl daemon-reload' to reload units.
I did the 'systemctl daemon-reload'
Nothing happened that I could see. Network manager still in the panel menu, but searching a network.
I did a re-start and it now works... lets see for how much time
W
1 Like
Upon re-booting this morning, no wifi
I again had to do
'sudo modprobe -r iwlwifi' and 'sudo modprobe iwlwifi'
then it connected
Good week to everybody
W
p.s. still can't figure what happens 'behind the scene'
If I may take an educated guess:
Your system boots without waiting for the WiFi firmware loading to be completed.
This means that you have to unload and reload it by hand
('sudo modprobe -r iwlwifi' and 'sudo modprobe iwlwifi')
From another thread, the same seems to be happening to GPU driver firmware. (resulting in black screen)
The remedy here was to switch from arctica-greeter to slick-greeter because a bug in arctica-greeter prevents the boot to wait for loading of the firmware.
Something that seems to be happening here too.
(but I might be totally mistaken)
So, it might be far fetched and even not remedy this issue but you might want to try to switch arctica-greeter to slick-greeter to let the desktop wait for the complete loading of the WiFi firmware. It's not an intrusive change and easy to revert.
2 Likes
I'll check that out. Thanks
W
Building on what Thom has said, if it is the Wifi pre-condition not being met, I believe you could add a condition to the appropriate file for systemd to wait for that condition before proceeding.
Once the pre-condition has been defined, you can confirm that the Network Manager will wait for it by getting the report from the command
systemctl list-dependencies NetworkManager
You likely need a definition similar to this
[Install]
WantedBy=multi-user.target (replace with correct value)
in the corresponding *.service file that initiates the WiFi service provided with iwlwifi.
Since I don't understand all of systemd, you will need to have someone who knows that better to guide you as to what the pre-condition parameter should be, how to specify its value, and where that should be done.
Saying that, you could at least perform this operation (which has way too much info) ...
systemd-analyze dump | cat -n >dump.txt
then do this to identify the network-related systemd Units ...
systemd-analyze dump | cat -n | grep '[-]> Unit' | grep '[Nn][Ee][Tt][Ww][Oo][Rr][Kk]'
giving you this (line numbers added by the above "cat -n")
14881 -> Unit NetworkManager.service:
17104 -> Unit network-pre.target:
18821 -> Unit systemd-networkd.socket:
26668 -> Unit NetworkManager-wait-online.service:
26998 -> Unit network.target:
36268 -> Unit network-online.target:
42207 -> Unit systemd-networkd-wait-online.service:
44907 -> Unit networking.service:
46603 -> Unit systemd-networkd.service:
50728 -> Unit networkd-dispatcher.service:
OR ... you could study the graph that comes from the command
systemd-analyze plot >bootup.svg
where you can spot items that are possibly of interest, such as these (zoomed cut-outs) which I've highlighted for my own system (in relative boot sequence):
Thom suggesting was interesting
but My system is already on slick-greeter, not arctica-greeter
A allow-guest=false
C greeter-wrapper=/usr/lib/lightdm/lightdm-greeter-session
D guest-wrapper=/usr/lib/lightdm/lightdm-guest-session
E greeter-session=slick-greeter
F user-session=mate
G xserver-command=X -core
H type=xlocal
H display-setup-script=/sbin/prime-offload
H display-stopped-script=/sbin/prime-switch
I greeter-show-manual-login=false
[LightDM]
B backup-logs=false
Sources:
A /usr/share/lightdm/lightdm.conf.d/50-disable-guest.conf
B /usr/share/lightdm/lightdm.conf.d/50-disable-log-backup.conf
C /usr/share/lightdm/lightdm.conf.d/50-greeter-wrapper.conf
D /usr/share/lightdm/lightdm.conf.d/50-guest-wrapper.conf
E /usr/share/lightdm/lightdm.conf.d/50-slick-greeter.conf
F /usr/share/lightdm/lightdm.conf.d/50-ubuntu-mate.conf
G /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf
H /usr/share/lightdm/lightdm.conf.d/90-nvidia.conf
I /etc/lightdm/lightdm.conf.d/91-arctica-greeter-mate.conf
W
There should be a simple solution resulting into a providing the 1 second time-out necessary for the WiFi firmware to load...
On another site I was recommended to put /sys/class/firmware/timeout at 0 vs 60 (apparently providing as much time as it needs to load firmware)... but it had no effect at my end.
W