forum.pistar.uk

I cant quite figure out whats going on here.
It might be something so simple I dont see it.


Starting update, please wait...
Stopping Services...
Done
Updating DV Binaries...
No updates for /usr/local/bin available
Done
Updating Pi-Star Binaries...
Updating /usr/local/sbin...
From https://github.com/AndyTaylorTweet/Pi-S ... aries_sbin
* branch master -> FETCH_HEAD
error: Your local changes to the following files would be overwritten by merge:
pistar-upnp.service
Please commit your changes or stash them before you merge.
Aborting
Updating ad2da0d..57b5de5
Updates were not successfull, reverting to Pi-Star original files...
error: Entry 'pistar-upnp.service' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'origin/master'.
Done

That looks like a repository issue the devs will have to fix.

The pistar-upnp.service file patch appears somehow to have become its own parent.

git error?

Error is duplicated here, and I've never edited /usr/local/sbin/pistar-upnp.service

Andy has fixed it up this morning, that should mean that everyone's problem ends when they next update.

It was a good update this morning. Seems like the issue was resolved.

Yes, but the upnp service syntax has been reverted to the original, so according to the upnpc man page it is incorrect when trying to delete upnp entries on stopping the service.

I expect Andy will sort it out soon, whatever the problem was it was due to something with the git commit.

System is also being left in RW mode after the updates.

KN2TOD wrote: ↑Tue Jul 07, 2020 8:01 pm System is also being left in RW mode after the updates.

That is a long running problem. Some updates will replace files, but the OS keeps a reference to the original file location (since the file is being used at the time). Those references are, in a way, "pending deletes" -- the name is no longer in the directory, but the OS can't free the space until after a reboot.

This was a different favor of that issue. I've never seen the update process itself report a problem with the mount/unmounts built into procedures, nor have the ability to correct the status by issuing an RPI-RW command later via SSH. I've seen enough RW lockups that your refer to, so this caught my attention. Six different hotspots exhibited the same behavior in a short period of time in sequential, manually initiated updates. All the hotspots were in R status before the update, RW status after, and restored to R status via command afterwards with no reboots.