'Brand new' Kiwi stuck in initial update loop? [fixed]
Hi. Just purchased, and have followed all instructions to initially power my Kiwi and Beaglebone Green kit. Everything has powered up OK but has been seemingly 'updating' for over 8 hours now. Can't connect using kiwisdr.local:8073, but when I go into my router and find the actual DHCP-assigned IP address, and use http://192.168.0.220:8073, I get "Sorry, software update in progress. Please check back in a few minutes. Or check sdr.hu for more KiwiSDR receivers available world-wide. Build: linking."
I also get the same message with "Build: compiling file #1" and "Build: done" etc. It just seems to be looping around this build process, and I'm nervous about interrupting this by powering it off.
The first blue status LED is double-pulsing continually, and the fourth LED flickers occasionally. The green ethernet light flickers occasionally too.
Any advice please?
Comments
It might be a Beaglebone Black actually. Don't know how to tell the difference. On login via PuTTY, I get:
BeagleBoard.org Debian Image 2016-05-13
Support/FAQ:
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian
Can I just check you did NOT put the sd card in the slot?
I'd power cycle it, if it is new (no configuration) and you have the SD card to hand there is little risk.
No, no SD card inserted :)
OK, power cycled. It's just gone back into the same loop...
Just realised that I can get into the admin interface, and on the 'Update' tab, I see "Installed version: v1.2, built Jun 9 2022 08:47:44
Update to version v1.538 in progress"
then
"Automatically check for software updates - Yes"
"Automatically install software updates - Yes"
Can you ssh to the Beaglebone and
"tail -f /var/log/messages"
There are other commands specific to the Kiwi (cdp, ml etc) but for now that should show where it is getting to and any fault messages like paraphrased "can't get to github"
SSH - if you are not familiar "PUTTY" from windows is the easiest to get going (IMO)
Nothing obvious here, other than a loop? After the "switching to new version 1.538" in appears to reboot to v1.2
Last login: Thu Jun 9 08:30:15 2022 from 192.168.0.10
root@kiwisdr:~# tail -f /var/log/messages
Jun 9 09:23:00 kiwisdr kiwid: 0:00:01 .... ### using SPI_DEV
Jun 9 09:23:01 kiwisdr kiwid: 0:00:02 .... FPGA version 1
Jun 9 09:23:01 kiwisdr kiwid: 0:00:02 .... CFG read /root/kiwi.config/kiwi .json: sdr_hu_register = false
Jun 9 09:23:04 kiwisdr kiwid: 0:00:05 .... (0 users)
Jun 9 09:23:04 kiwisdr kiwid: 0:00:05 .... UPDATE: scheduled
Jun 9 09:23:04 kiwisdr kiwid: 0:00:05 .... DDNS: private ip 192.168.0.220/ 24
Jun 9 09:23:04 kiwisdr kiwid: 0:00:05 .... DDNS: public ip 82.15.234.51
Jun 9 09:28:34 kiwisdr kiwid: 0:05:35 .... UPDATE: checking for updates
Jun 9 09:28:35 kiwisdr kiwid: 0:05:36 .... UPDATE: version changed, curren t 1.2, new 1.538
Jun 9 09:28:35 kiwisdr kiwid: 0:05:36 .... UPDATE: building new version..
Jun 9 09:33:40 kiwisdr kiwid: 0:10:41 .... UPDATE: switching to new version 1.538
Jun 9 09:34:11 kiwisdr kiwid: 0:00:00 .... KiwiSDR v1.2 --------------------------------------------------------------------
Jun 9 09:34:11 kiwisdr kiwid: 0:00:00 .... compiled: Jun 9 2022 09:29:11
Jun 9 09:34:11 kiwisdr kiwid: 0:00:00 .... reading configuration from file /root/kiwi.config/kiwi.json
Jun 9 09:34:12 kiwisdr kiwid: 0:00:01 .... serial number from EEPROM: 6212
Jun 9 09:34:12 kiwisdr kiwid: 0:00:01 .... reading configuration from file /root/kiwi.config/dx.json
Jun 9 09:34:12 kiwisdr kiwid: 0:00:01 .... 883 dx entries
Jun 9 09:34:12 kiwisdr kiwid: 0:00:01 .... listening on port 8073 for "openwebrx"
Jun 9 09:34:12 kiwisdr kiwid: 0:00:01 .... webserver for "openwebrx" on port 8073
Jun 9 09:34:12 kiwisdr kiwid: 0:00:01 .... ### using SPI_DEV
Jun 9 09:34:13 kiwisdr kiwid: 0:00:02 .... FPGA version 1
Jun 9 09:34:13 kiwisdr kiwid: 0:00:02 .... CFG read /root/kiwi.config/kiwi.json: sdr_hu_register = false
Jun 9 09:34:15 kiwisdr kiwid: 0:00:04 .... (0 users)
Jun 9 09:34:15 kiwisdr kiwid: 0:00:04 .... UPDATE: scheduled
Jun 9 09:34:16 kiwisdr kiwid: 0:00:05 .... UPDATE: checking for updates
Jun 9 09:34:16 kiwisdr kiwid: 0:00:05 .... UPDATE: version changed, current 1.2, new 1.538
Jun 9 09:34:16 kiwisdr kiwid: 0:00:05 .... UPDATE: building new version..
Jun 9 09:34:18 kiwisdr kiwid: 0:00:07 .... DDNS: private ip 192.168.0.220/24
Jun 9 09:34:18 kiwisdr kiwid: 0:00:07 .... DDNS: public ip 82.15.234.51
Latest loop contained a new 'action 17 suspended' messages:
Jun 9 09:51:35 kiwisdr kiwid: 0:00:00 .... KiwiSDR v1.2 --------------------------------------------------------------------
Jun 9 09:51:35 kiwisdr kiwid: 0:00:00 .... compiled: Jun 9 2022 09:46:29
Jun 9 09:51:35 kiwisdr kiwid: 0:00:00 .... reading configuration from file /root/kiwi.config/kiwi.json
Jun 9 09:51:35 kiwisdr kiwid: 0:00:00 .... serial number from EEPROM: 6212
Jun 9 09:51:35 kiwisdr kiwid: 0:00:00 .... reading configuration from file /root/kiwi.config/dx.json
Jun 9 09:51:35 kiwisdr kiwid: 0:00:00 .... 883 dx entries
Jun 9 09:51:35 kiwisdr kiwid: 0:00:00 .... listening on port 8073 for "openwebrx"
Jun 9 09:51:35 kiwisdr kiwid: 0:00:00 .... webserver for "openwebrx" on port 8073
Jun 9 09:51:36 kiwisdr kiwid: 0:00:01 .... ### using SPI_DEV
Jun 9 09:51:37 kiwisdr kiwid: 0:00:02 .... FPGA version 1
Jun 9 09:51:37 kiwisdr kiwid: 0:00:02 .... CFG read /root/kiwi.config/kiwi.json: sdr_hu_register = false
Jun 9 09:51:39 kiwisdr kiwid: 0:00:04 .... (0 users)
Jun 9 09:51:39 kiwisdr kiwid: 0:00:04 .... UPDATE: scheduled
Jun 9 09:51:40 kiwisdr kiwid: 0:00:05 .... UPDATE: checking for updates
Jun 9 09:51:40 kiwisdr kiwid: 0:00:05 .... UPDATE: version changed, current 1.2, new 1.538
Jun 9 09:51:40 kiwisdr kiwid: 0:00:05 .... UPDATE: building new version..
Jun 9 09:51:40 kiwisdr rsyslogd-2007: action 'action 17' suspended, next retry is Thu Jun 9 09:52:10 2022 [try http://www.rsyslog.com/e/2007 ]
Jun 9 09:51:42 kiwisdr kiwid: 0:00:07 .... DDNS: private ip 192.168.0.220/24
Jun 9 09:51:42 kiwisdr kiwid: 0:00:07 .... DDNS: public ip 82.15.234.51
Jun 9 09:56:47 kiwisdr rsyslogd-2007: action 'action 17' suspended, next retry is Thu Jun 9 09:57:17 2022 [try http://www.rsyslog.com/e/2007 ]
Jun 9 09:56:52 kiwisdr kiwid: 0:05:17 .... UPDATE: switching to new version 1.538
"UPDATE: switching to new version" should mean it has worked.
From another thread - proper instructions (without requiring SSH)
(jks) If the admin page works go to the "update" tab, click "build now". Then the "console" tab, click "connect", and type "m blog" into the field at the bottom that says "enter shell command".
(BTW sorry about not reading your "logon via PuTTY" comment properly, I'm glancing at the forum between work issues).
OK, did a manual "check for software update", then clicked "build now" button, but there is no "console" tab?
It's just rebooted to v1.2 again.
OK so something about the update is failing, I have seen this before and I think it needs manual intervention, if JKS doesn't come in I'll look for a relevant thread.
Can you get to https://github.com/jks-prv/Beagle_SDR_GPS OK from your connection?
(for interest what IP address does "nslookup github.com" return?)
There was one github issue from one location some time back.
I'm occasionally seeing "server will reboot after build" message in admin panel, so I tried adding an admin password, as found in this thread: https://forum.kiwisdr.com/index.php?p=/discussion/2346/will-not-update-fixed
but no change. I havn't power-cycled the device since you originally suggested it...
As you are in via SSH you could just do a clean Git pull (as root)
cd
mv Beagle_SDR_GPS B.bad
gclone Beagle_SDR_GPS
cdp
up
Before that stopping the kiwi server would makes sense so
cdp
kd
then the commands above
Yes, I can get to that github address from my Win7 machine, and download the .zip
Command line output attached for nslookup.
I originally had a VPN on my workstation (now turned off) but it was only on my local machine, not my router so the WAN IP address as used by the Kiwi/Beagle is my real address.
I assume you can "ping github.com" OK from the Kiwi too?
At this stage I'll probably back out as I don't want to populate the thread completely with posts John needs to correct.
We have
With sucessfull ping to github, and ssh access, a fresh copy makes the most sense to me.
I get a positive response when pinging github from the Kiwi, but it doesn't resolve the IP to the correct github IP? Looks like a proxy from my ISP?
Good spot...
I've seen it where John rerouted the github pull command to avoid a github issue from Manchester UK.
The other IP addresses you posted seem to be US ones, are you based in the UK?
--edit-- from a quick wed search can you check your VirginMedia settings - "Turn off web safety settings"
When I do the same from my windows workstation I get this:
I don't understand why...
I guess it's my VPN's static DNS IP's as opposed to my ISP's default DNS addresses...
It seem to be a VM "safety" issue. I'm not sure if they allow adults to turn it off.
One other thing that occurs to me is to put the github address you resolved from your workstation, into the host file of the Kiwi, that way it should not get hijacked by VM safety, unless they do full routing based on IP rather than DNS.
nano /etc/hosts
add
140.82.113.3 github.com
Save then try ping again and it that responds just tell it to reboot and see what happens (you can ssh in and watch the logs).
I'm in the UK. I've updated my DNS settings multiple times over the years, so they could be from anywhere. I've always avoided using my ISP's DNS servers (I've been with many ISP's too) but now let my VPN provider use their own DNS's for my workstation & Linux laptop at the moment. I'll try your suggestion re VM settings next.
OK, can't easily change my VM web 'safety' nonsense, so have edited the hosts file on the Kiwi, and a re-ping gave me the expected (correct) IP results.
Power cycled the Kiwi, and currently monitoring the logs via PuTTY, and it's looking promising.
Taking much longer (20 mins and counting) on the "UPDATE: building new version.." step, so fingers crossed. Lost access to the admin panel, and message banner on the Kiwi's LAN IP address has changed - no longer shows the build progress.
I'll leave it for an hour or so and let you know.
Thanks for your support. I really appreciate it.
OK fingers crossed, bear in mind the root password, if not set, will be changed to the serial number of the Kiwi.
It's easier to assist someone who uses SSH, DNS already and you spotted the proxy so that will help others. Hopefully I'll remember this one for the next VM user.
Success, thank you very much. Timely, quality support is everything!
Looking forward very much to joining the community.
Excellent!
Welcome to Kiwi BTW.
Might pay to edit the hosts file to remove the github address, if you manage to turn off the VM proxy. No hurry as it worked, but could save some head scratching later.
Not sure I followed all that completely (it's 4AM and coffee hasn't taken effect yet). But the original 5 minute interval between "building new version..." and "switching to version" is 10x shorter than it should be. At least for the first build in an update from v1.2.
We've had trouble in the past with ISP DNS interference and the use of the git protocol (versus http) fetching git files (the main Makefile has workarounds for both of these cases).
Thanks Stu for sorting this.
As an addendum, I went on to set my Beaglebone up with a static IP address, which allowed me to define third-party (non Virgin Media) Domain Name Servers, which in turn gets around the problems with VM 'safety' settings, and gives me more privacy as well.
I then deleted the github.com entry in my hosts file, so all back to standard, and no nasty tripwires in the future.
Thanks again for your help, and I hope this thread helps someone else. I think there will be more and more of this 'protection' applied on our behalves as time goes on.
On reflection setting a static IP would have been the least command line intensive method out of the initial ISP issue.
I think you are right on filtering becoming more common. It is going to be hard to put mechanisms in place to detect all kinds of ISP blocks, filtering and DNS hijacks.
It does make me wonder if there could be a "failed-to-new-version" flag that gets tripped if that happens more than three times in a 24hr period, halts the process while setting the LEDS to Pause mode - something like centre out flashing.