Sorry, I thought you mean the tv screen that the pi was attached to.
I searched for linux screen and now understand your comment. It would help, but it seems better if the connman stuff could get updated to the latest debian fix, so that that a straight ssh update would work correctly.
I did notice that the pi that went unresponsive eventually came back (with a differently ip address) and seems to work ok, so that the upgrade probably finished properly.
I’d offer to help, but I have no idea how the tool chain/etc for OSMC works.
We don’t use the Debian conman package, we have our own package with our own systemd service and our own package scripts so we will not be affected by the above referenced bug.
I will go over the package scripts again to see if I can spot any bugs however upgrading of the conman package and checking networking comes back up afterwards has been fairly thoroughly tested, with this being the first reported instance of this issue…
I have upgraded the connman package many times via ssh and I never use screen, nor should you need to.
We really need logs to be able to catch this - in particular the apt logs. These logs are persistent so can be uploaded after a reboot.
PS that bug report says the fix was included in connman 1.26 - we already have 1.28 which is the latest version which will include that fix, so this is not your issue.
To upgrade connman we must stop the service (therefore disabling networking) before dpkg can extract the new version of connman. Then after files are extracted and replaced it will be restarted again. This is done by these two debian package scripts:
If you’re just updating the connman package alone typically this means the network would be down for about 10 seconds, however if a lot of packages are being upgraded in addition to connman it could be much longer, maybe a couple of minutes. As long as you don’t press a key on your ssh session it should resume when the connection comes back up.
The real issue though is that your Pi got a different IP address from your DHCP server - we have no choice but to shut down connman and restart it to upgrade it, however we have no control over the IP address assigned by the DHCP server so it entirely possible for this IP address to be different thus effectively break the ssh connection.
Connman already asks for the previous IP address specifically (dhcp client hint) when acquiring an address and MOST DHCP servers will honour this request unless it would cause an IP address conflict with another device. (Unlikely in such a short period of time)
The fact that you got a different IP address when disconnecting for probably less than a minute means either your DHCP server is not very well behaved, or that you have multiple DHCP servers on the same network allocating different ranges. (Thus your IP address might bounce between a couple of different addresses)
Not a whole lot that we can do about this I’m afraid. The good news is that APT is smart enough to keep installing if the controlling terminal (eg the ssh session) dies - this means that if you were to log in to the local console and run top you would see that APT is still actually running and will finish the entire dist-upgrade, provided you don’t go pulling the power plug thinking it’s hung…
So if you seem to lose the network connection during an upgrade give it 5-10 minutes to complete then try to connect again, keeping in mind that it might be on a different IP address depending on your DHCP setup.