My station must have rebooted last night as there was a flatline segment for about 10 minutes. I checked the rs.local interface and saw that the system version is now 0.20. Everything looks OK signal wise both locally and on the web. However, the System Status states the system is “Booting”, but it is working perfectly. I rebooted, get the same message, and as before the system is connected and working as expected. I attached a screen dump of the Shake Config.
Thank you for notifying us about this. It has not come up during the testing phase, and all the Shakes reported a RUNNING status after their update to v0.20.
Can you please try to shut it down, disconnect the power cable, wait for around 5 minutes, and turn it on again?
Is the BOOTING status still there? In that case, could you please donwload the logs from the Shake and post them here?
Powered it down and cleaned out a little spider community while at it. It’s up and running now, but the status still shows “booting”. I’ve attached the log files for your inspection.
I’m looking at the upgrade.log and at the bottom after stating the system is updating to 0.2 it states:
2022 046 10:22:11: Updating Docker image registry.gitlab.com/rshake-public/rsh-data-consumer
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
2022 046 10:22:11: Software updates complete.
@Stormchaser Any updates on this? Also, has the 0.20 update been pulled? I ask because it looks that way in github and my shake3d and boom are showing as being on the latest when it looks for updates.
Since my other two shakes (a 3D and a Boom) updated to 0.20 with no issues, I decided to do some investigation, starting with looking at postboot.log. I saw some gibberish in the file, and could see from the log what program likely caused it.
I ended up replacing the following three files with copies from the Boom:
there was indeed a problem with the initial release of v0.20 causing the STATUS message to “get stuck” on BOOTING. to note: neither data-flow nor connection to the server was affected by this. the release was subsequently refreshed.
mr. jkline’s solution is the good one. for those users who do not have multiple shakes to make this copy, please find attached a compressed tar file containing the fixed programs. props to jkline for digging into the details and figuring this out before i was able to respond properly here on the forum, and my apologies for the delay.
specific instructions to install the fix:
# after copying the attached file to the /tmp directory on the Shake
> cd /tmp
> bunzip2 bin.v20.tar.bz2
> cd /usr/local
> sudo tar xf /tmp/bin.v20.tar
> sudo reboot
cheers, apologies for any confusion caused,
richard
For once my Shake took the update, rebooted, and is in “Running” state as expected. I don’t know if I just got the later fixed version, or it worked out of the box. But, if I had not read this message, I wouldn’t even have known it updated. Good to see!
My only Raspberry Shake (a 4D) has been stuck in this “BOOTING” stage ever since the 0.20 release came out, even though it worked fine locally and produced data I could see in the helicorder plots just by logging into rs.local on my home network. I finally found this thread, downloaded the zipped tar file with the updates, installed them, and my RS4D is back on the air! Thank you so much for this fix!!! Hopefully 0.20 gets an update that resolves the problem.
