Andrew Shadura wrote:
>On 28 November 2017 at 10:24, RjY <r...@users.sourceforge.net> wrote:
>> I'm still observing this on upgrade from 2:2.4-1.1 to 2:2.6-8.
[...]
>> As workaround I did "sudo update-rc.d hostapd disable" (Wasn't sure what
>> the systemctl equivalent is) then "sudo dpkg --configure hostapd"
>> unbroke dpkg. Apparently the call to "systemctl mask hostapd.service" in
>> postinst had no effect? (or was not performed)
>Well, that was something I haven't thought about carefully. Probably I
>need to mask the unit every time when (during upgrades or
>reinstallation) we find out /etc/defaults/hostapd is unconfigured
>*and* hostapd isn't already running.
I think unfortunately it needs to be more than just "hostapd isn't
running" - in my case hostapd *was* already running, started via
ifupdown:
iface netw inet static
hostapd /etc/hostapd/hostapd.conf
address xxx.xxx.xxx.xxx
network xxx.xxx.xxx.xxx
netmask xxx.xxx.xxx.xxx
broadcast xxx.xxx.xxx.xxx
up start-stop-daemon -S -o -p /run/udhcpd.pid -x /bin/busybox --
udhcpd -S /etc/hostapd/udhcpd.conf
down start-stop-daemon --signal KILL -K -o -p /run/udhcpd.pid -x
/bin/busybox
(which is probably a bit strange, but works well enough for me, so I've
yet to attempt to port it to a systemd unit)
So I guess it needs to be "mask the unit if /etc/defaults/hostapd isn't
configured and hostapd isn't already started by a sysv init script or
systemd unit". Or just simply "mask the unit if /etc/defaults/hostapd
isn't configured" - does it matter if it is already running or not?
--
https://rjy.org.uk/
