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

[Thibaut]

> 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.

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

IMHO hostapd should be fixed instead.

My 2c,
T.