Looks to me like the initramfs loads the driver for the wireless card, iwlwifi, but the initramfs doesn't have the patched firmware.
Maybe try adding to your boot options blacklist=iwlwifi, to prevent the initramfs from loading the driver, leaving it up to the main system when it starts to take control?
linux /boot/vmlinuz-[xxx] root=UUID=[yyy] ro quiet splash blacklist=iwlwifi ---
Another one tells me to update firmware from this site:
W
It's unclear to me what happened when you tried a live USB. Your post seems to say that it fails with the same error.
My question would be - What version of the live USB did you use? If you used a 24.10 live USB you should also try earlier versions to see if they work. If they do work and 24.10 doesn't, then we can conclude it's a software problem.
If it fails with the older versions in the same manner, that would tell me it's probably a hardware failure. Aging component gets hot, breaks connection, yada yada yada. I would re-seat the wifi card if it has one.
Best of luck. It looks like you have many people interested in the problem. I'm looking forward to finding out what the problem is.
I was OK for a few days. Now the problem is back.
A few small software updates in the meantime.
same error:
31.083808] iwlwifi 0000:00:14.3: Failed to start RT ucode: -110
[ 31.083815] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 13 fired (delay=0ms).
[ 32.129354] iwlwifi 0000:00:14.3: Failed to run INIT ucode: -110
W
The USB is with 24.10 The one I used for fresh install.
W
MDD12
It didn't work either booting with a 24.04 USB. But the lspcicommand doesn't list any problem with the PCI devices
W
Guys
Just got an automatic Linux-firmware update minutes ago.
I rebooted and the wifi did connect
Hope it will persist
*** Note: Well it didn't. It disconnected by itself a few times since this morning. No suspend. I rebooted and it reconnected... for maybe an hour or less. Now tethering again to write this ***
W
p.s. I do sincerely thank all of those here for your time & efforts to help me out. But I was probably missing something in the way to a solution.
Today if I do
'sudo systemctl status NetworkManager'
I get this, for those who know how to read:
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; preset: enabled)
Active: active (running) since Sun 2024-11-24 08:20:16 EST; 3h 5min ago
Invocation: a8ab56bf84324a1a8ecdbc5caf47be2c
Docs: man:NetworkManager(8)
Main PID: 1568 (NetworkManager)
Tasks: 4 (limit: 13896)
Memory: 14M (peak: 29.8M)
CPU: 2.116s
CGroup: /system.slice/NetworkManager.service
└─1568 /usr/sbin/NetworkManager --no-daemon
Nov 24 11:25:05 valpomar NetworkManager[1568]: [1732465505.4040] device (p2p-dev-wlo1): supplicant management interface state: disconnected -> scanning
Nov 24 11:25:06 valpomar NetworkManager[1568]: [1732465506.8238] device (wlo1): supplicant interface state: scanning -> authenticating
Nov 24 11:25:06 valpomar NetworkManager[1568]: [1732465506.8239] device (p2p-dev-wlo1): supplicant management interface state: scanning -> authenticating
Nov 24 11:25:09 valpomar NetworkManager[1568]: [1732465509.4208] device (wlo1): supplicant interface state: authenticating -> disconnected
Nov 24 11:25:09 valpomar NetworkManager[1568]: [1732465509.4209] device (p2p-dev-wlo1): supplicant management interface state: authenticating -> disconnected
Nov 24 11:25:17 valpomar NetworkManager[1568]: [1732465517.6299] device (wlo1): Activation: (wifi) association took too long, failing activation
Nov 24 11:25:17 valpomar NetworkManager[1568]: [1732465517.6300] device (wlo1): state change: config -> failed (reason 'ssid-not-found', sys-iface-state: 'managed')
Nov 24 11:25:17 valpomar NetworkManager[1568]: [1732465517.6305] manager: NetworkManager state is now DISCONNECTED
Nov 24 11:25:17 valpomar NetworkManager[1568]: [1732465517.6310] device (wlo1): Activation: failed for connection 'COWIFI2767344348/0'
Nov 24 11:25:17 valpomar NetworkManager[1568]: [1732465517.6314] device (wlo1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
So it says: wifi association took too long.
Hardware doesn't show any problem.
iwlwifi active. Firmware up to date.
Still searching.
W
Hi Watford,
I still think you would find some insights into your problem by studying the output of
and looking at the details associated with "Network Manager", which under the heading
Unit NetworkManager.service:
to get at some of the details regarding specific interractions and dependencies, would help pinpoint the issue.
Other than that, I would suggest trying removing the "--no-daemon" option, so that Network Manager can respond and recover from any issues of dependencies and timing on its own, without manual intervention.
Here is yet another idea. Could you use a wifi dongle to prove or falsify theory of a hardware failure resulting in that floating error?
Eric
I did read through your note of Nov 11. I tried the lines you suggested but I get nothing and not knowledgeable enough to understand all of it.
If I use: systemd-analyze dump | cat -n >dump.txt
I get.... nothing
W
Guys
I don't want to count the chickens before they’re hatched...
But it's been 2 days now without wifi connection issues... after a Nvidia update... Could be something else, but it is the only 'event' I've seen in the interim.
Lets see
W
The output of that (dump.txt) has over 65K lines on my system in its current state.
Lines that give hints as to interactions for leads on what is breaking down where are the lines:
8037 -> Unit NetworkManager.service:
***
8062 Assert Timestamp: Tue 2024-11-26 11:56:36 EST
8063 Assert Result: yes
8064 Requires: sysinit.target (origin-default)
8065 Requires: dbus.socket (origin-file)
8066 Requires: system.slice (origin-file)
8067 Wants: network.target (origin-file)
8068 RequiredBy: NetworkManager-wait-online.service (destination-file)
8069 WantedBy: multi-user.target (destination-file)
8070 Conflicts: shutdown.target (origin-default)
8071 Before: NetworkManager-wait-online.service (destination-file)
8072 Before: update-notifier-download.timer (destination-file)
8073 Before: shutdown.target (origin-default)
8074 Before: network.target (origin-file)
8075 Before: multi-user.target (destination-default)
8076 Before: apt-daily-upgrade.service (destination-file)
8077 Before: apt-daily.service (destination-file)
8078 Before: update-notifier-motd.timer (destination-file)
8079 After: dbus.socket (origin-file)
8080 After: sysinit.target (origin-default)
8081 After: network-pre.target (origin-file)
8082 After: systemd-journald.socket (origin-file)
8083 After: basic.target (origin-default)
8084 After: system.slice (origin-file)
8085 After: dbus.service (origin-file)
8086 References: network-pre.target (origin-file)
8087 References: shutdown.target (origin-default)
8088 References: systemd-journald.socket (origin-file)
8089 References: dbus.service (origin-file)
8090 References: system.slice (origin-file)
8091 References: sysinit.target (origin-default)
8092 References: network.target (origin-file)
8093 References: basic.target (origin-default)
8094 References: dbus.socket (origin-file)
8095 ReferencedBy: NetworkManager-wait-online.service (destination-file)
8096 ReferencedBy: update-notifier-motd.timer (destination-file)
8097 ReferencedBy: apt-daily.service (destination-file)
8098 ReferencedBy: apt-daily-upgrade.service (destination-file)
8099 ReferencedBy: update-notifier-download.timer (destination-file)
8100 ReferencedBy: multi-user.target (destination-file destination-default)
8101 InSlice: system.slice (origin-file)
You could then examine the segments relating to the individual segments highlighted, in the various logs, in order to pinpoint the cause of the "failed start" or the cause of the sudden "disabling/failure" of the necessary services.
Those identify all the direct dependencies for the Network Manager itself. But if the failure is not at the first level of dependency, you then need to dig into the deeper dependencies for each of those, in order to track down the point of failure, or the trigger for the unwanted offline state.
Hope that helps.
Eric
As per my previous note, I am now wifi connected...for now...
But your indications are quite interesting. I'll dig in.
Thanks
W
If you want to try different kernels, perhaps this would be the way to go: GitHub - bkw777/mainline: Install mainline kernel packages from kernel.ubuntu.com
It's available on a PPA, e.g.
sudo add-apt-repository ppa:cappelikan/ppa
sudo apt update
sudo apt install mainline
Thanks Stephen
I was to try it and then (suddenly) wifi started to connect with no glitch...
I still wonder why... some recent update(s) seems to have solved the issue. Which ? How ? ...no idea... but it works.
Maybe a 'backport' or solution sent for what seemed to be a iwlwifi or Intel Wi-Fi 6 AX201 driver issue. 
So for now I'll shy away from any further actions...
Again many thanks to all of you here above
W