[PATCH] base-files: stage2: stop Wi-Fi service on firmware upgrade

[Florian Eckert]

On 2025-11-13 10:04, Thibaut wrote:
>> Le 13 nov. 2025 à 09:58, Florian Eckert <fe at dev.tdt.de> a écrit :
>> 
>> It may happen that the WiFi service cannot be stopped with a 'TERM' 
>> and
>> 'KILL' signal. As a result the firmware upgrade is failing with the
>> following log messages.
>> 
>> Mon Nov  3 21:28:06 CET 2025 upgrade: Sending KILL to remaining 
>> processes ...
>> Mon Nov  3 21:28:06 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5664)
>> Mon Nov  3 21:28:09 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:11 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:13 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:15 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:17 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:19 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:22 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:24 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:26 CET 2025 upgrade: Sending signal KILL to hostapd 
>> (5688)
>> Mon Nov  3 21:28:28 CET 2025 upgrade: Failed to kill all processes.
>> sysupgrade aborted with return code: 256
>> 
>> It appears that this is because clients remain connected to the system
>> via Wi-Fi during the system upgrade. The script call '/sbin/wifi down'
>> before sending the 'TERM' and 'KILL' signal fixes the problem and the
>> sysupgrade is completed successfully.
> 
> Err, isn’t this working around the actual issue here? It seems like a
> (serious?) problem that a process cannot be KILLed.

You may be right. When creating the patch, I thought about why hostapd
does not respond to KILL!

> This is bound to affect regular reboots as well, which in turn will
> have other consequences for end users.

I haven't seen any problems with that. The reboot has always worked so
far. The problem with KILL doesn't seem to be relevant on reboot.

> IMHO hostapd should be fixed instead.

Of course, that would be the best solution, but currently it is a
problem and I do not believe that the problem will be found quickly.

I don't know where to start in hostpad. It may also depend on drivers
(ath10k, ath11k, ...) and Wi-Fi firmware?

--
Florian