The Kiwi is being assigned the usual LAN address by the router, and I am able to ssh into the Beaglebone using the default password, so at least that part is "alive".
Have you tried restarting or power-cycling since the restart after flashing? Sometimes things just get stuck for unknown reasons. Since you're ssh'd in do a safer restart via the restart command (as root) rather than simply pulling the plug.
If that doesn't work time to look at the log. Try this:
cdp
ms (alias for "make status", takes some time before output
Use the space key to see the next full screen of messages, if any. Note any error messages and also the time and process ID associated with those messages. Then do it again and see if the Kiwi process is looping getting the same error.
I've restarted it a few times with no success. I'm not a Linux user so I'm not sure how to be logged in as root. I am logging in as user debian with 'temppwd' as the password. when I try typing 'cdp' it says command not found. i also tried 'su cdp' and it says 'user cdp does not exist'.
I should also mention I have a second KiwiSDR with the same DB 8.5 and version 1.815 software that I also tried upgrading to DB 11 with no luck (4G and 32GB cards tried), in that case I was never able to get the boot off the SD card to go forward like with this one by holding down the magic button. So it's still alive and running with DB 8.5 v1.815...but I will say the second KiwiSDR has always been very sluggish to access the admin menu, usually at least 30 seconds to respond.
Okay, I wasn't sure how much you knew. Once someone knows how to ssh it's a pretty good bet they know all the rest. When logged in using account "debian" do a sudo su and give the root account password which should be the same as the Kiwi serial number. If not, try the admin password.
After that things like cdp and ms should work.
But that second Kiwi made it through the admin backup page upgrade button procedure without errors?
Thanks for the extra Linux "hand holding", and yeah, 'name-dropping' the ability to ssh in does make it sound like one is a "pro" ;>. I'll give the 'sudo su' a try today.
The second Kiwi did successfully write the DB11 image to the card, but when restarted I could never get it to boot off the disk, despite several attempts with holding down the button on the board. But maybe that was only with the 4GB card, so I need to go back now and try the 32GB card too. As I mentioned though, the second Kiwi has always been quite sluggish to start in comparison to the first one, especially with the admin page loading.
OK attached is a photo of the ssh session on the non-functioning Kiwi. Note the bash errors upon login, don't know if that has any signifcance. I tried to connect again at 192.168.1.80:8073 using either Chrome or Firefox with no luck.
I don't know what that bash error is. Probably not of great significance. But perhaps an indication of an unclean shutdown (pulling power in the middle of a disk [eMMC] write).
What's more concerning is further down where the Kiwi server only ran 6 seconds before exiting. I'll bet if you do an "msl" instead of "ms" you'll see it in a loop with some kind of recurring error. That sort of thing is not visible with an "ms".
Since I don't care about losing any customization it seems like the easiest remedy would be to download a standard Kiwi 1 image with Debian 11 if that is available. If anyone can point me to that I'd be grateful.
So the problem with those screen captures is that they're log messages from 5 months ago -- Feb 20 & 21. Look at the times on the left of each message. When running the msl command you'll get thousands of messages dumped. What I really want to see is the last few hundred, going backwards in time. Better yet to copy/paste the entire result and email it as a file to support@kiwisdr.com
Yes, you can prepare an sd card to re-flash from scratch. But doing so shouldn't be substantially different from the backup page upgrade function. But worth trying nonetheless.
The 'msl' command only yielded those four screen caps of results, at which point it said "connection closed" and returned to the root directory command prompt (at the end of part 4 file). I went back today and tried to ssh in again, but I was unable, since it kept saying "connection refused". I assume the Feb 21 date came from the version of the software in the image (think it was v 1.804?).
But I WAS able to get a default factory image to load OK so that Kiwi is back up and running, and I just updated to v 1.815 with no issues. In hindsight I should have done that from the beginning since the customization level was fairly modest. The only customization on the Kiwi that was a bit unusual was that I had changed the host name to something like Kiwi1 or Kiwi2 since I have two in the same LAN that I wanted to connect to using a host name. May have to "re-learn" how I did that.
I'll proceed to see if I can get the factory image to update the second Kiwi now.
Interesting. The Feb 20/21 date/time is when the particular log message was recorded. Note in part 4 that I was logging in as a user. I wonder if we were chasing some problem back then. I couldn't find anything in my notes or email about that. Maybe just coincidence.
v1.803/4 isn't that old. But perhaps there is a problem with it and the backup page upgrade scheme. Glad the re-flash with the base image + v1.815 upgrade worked out. Apologies for all the trouble.
About hostnames: By default all Kiwi have the hostname "kiwisdr". And the software that implements the "kiwisdr.local" name you can use in a URL knows to name multiple Kiwi of the same name as "kiwisdr" (first one), "kiwisdr-1", "kiwisdr-2" etc. (although I can't remember if the numbering starts at "1" or "2"). In later software releases there is also a new field on the network tab called "Debian hostname" for making such a change. No need to edit the /etc/hostname file directly.
No apologies necessary for my struggles with the upgrade to DB11. Happy to report that I was able to get the factory default image installed fine on my second Michigan KiwiSDR, so both are now DB11s running v 1.815 software.
A side benefit on the second Kiwi is that it is no longer sluggish, with the admin page loading as fast as the the other Kiwi.
Now that things are up and running again I guess I should see if I can cause problems by installing the tailscale VPN on these two ;>). Never tried that on these two, but on my two Kiwis in another state the tailscale works great for remote access.
Comments
Kiwi version 1.
Yes, Kiwi and computer are on the same LAN.
The Kiwi is being assigned the usual LAN address by the router, and I am able to ssh into the Beaglebone using the default password, so at least that part is "alive".
Fine ! A few hours left before sunrise... 😉
Pre-sunrise. Freezing cold. I hate NZ winters..
Have you tried restarting or power-cycling since the restart after flashing? Sometimes things just get stuck for unknown reasons. Since you're ssh'd in do a safer restart via the
restartcommand (as root) rather than simply pulling the plug.If that doesn't work time to look at the log. Try this:
cdp
ms (alias for "make status", takes some time before output
Use the space key to see the next full screen of messages, if any. Note any error messages and also the time and process ID associated with those messages. Then do it again and see if the Kiwi process is looping getting the same error.
I've restarted it a few times with no success. I'm not a Linux user so I'm not sure how to be logged in as root. I am logging in as user debian with 'temppwd' as the password. when I try typing 'cdp' it says command not found. i also tried 'su cdp' and it says 'user cdp does not exist'.
I should also mention I have a second KiwiSDR with the same DB 8.5 and version 1.815 software that I also tried upgrading to DB 11 with no luck (4G and 32GB cards tried), in that case I was never able to get the boot off the SD card to go forward like with this one by holding down the magic button. So it's still alive and running with DB 8.5 v1.815...but I will say the second KiwiSDR has always been very sluggish to access the admin menu, usually at least 30 seconds to respond.
Okay, I wasn't sure how much you knew. Once someone knows how to ssh it's a pretty good bet they know all the rest. When logged in using account "debian" do a
sudo suand give the root account password which should be the same as the Kiwi serial number. If not, try the admin password.After that things like
cdpandmsshould work.But that second Kiwi made it through the admin backup page upgrade button procedure without errors?
Thanks for the extra Linux "hand holding", and yeah, 'name-dropping' the ability to ssh in does make it sound like one is a "pro" ;>. I'll give the 'sudo su' a try today.
The second Kiwi did successfully write the DB11 image to the card, but when restarted I could never get it to boot off the disk, despite several attempts with holding down the button on the board. But maybe that was only with the 4GB card, so I need to go back now and try the 32GB card too. As I mentioned though, the second Kiwi has always been quite sluggish to start in comparison to the first one, especially with the admin page loading.
OK attached is a photo of the ssh session on the non-functioning Kiwi. Note the bash errors upon login, don't know if that has any signifcance. I tried to connect again at 192.168.1.80:8073 using either Chrome or Firefox with no luck.
I don't know what that bash error is. Probably not of great significance. But perhaps an indication of an unclean shutdown (pulling power in the middle of a disk [eMMC] write).
What's more concerning is further down where the Kiwi server only ran 6 seconds before exiting. I'll bet if you do an "msl" instead of "ms" you'll see it in a loop with some kind of recurring error. That sort of thing is not visible with an "ms".
Attached are four screen caps that capture all of the output after entering the 'msl' command, in case it id of use to figure out what it's doing.
Since I don't care about losing any customization it seems like the easiest remedy would be to download a standard Kiwi 1 image with Debian 11 if that is available. If anyone can point me to that I'd be grateful.
Hi,
You can read the procedure from this point :
The image file is a bit lower in the page.
It would be interesting to understand what went wrong in your update (not enough free space on the disk ?) May be, let John investigate a bit more ?
Best wishes,
T
So the problem with those screen captures is that they're log messages from 5 months ago -- Feb 20 & 21. Look at the times on the left of each message. When running the msl command you'll get thousands of messages dumped. What I really want to see is the last few hundred, going backwards in time. Better yet to copy/paste the entire result and email it as a file to support@kiwisdr.com
Yes, you can prepare an sd card to re-flash from scratch. But doing so shouldn't be substantially different from the backup page upgrade function. But worth trying nonetheless.
The 'msl' command only yielded those four screen caps of results, at which point it said "connection closed" and returned to the root directory command prompt (at the end of part 4 file). I went back today and tried to ssh in again, but I was unable, since it kept saying "connection refused". I assume the Feb 21 date came from the version of the software in the image (think it was v 1.804?).
But I WAS able to get a default factory image to load OK so that Kiwi is back up and running, and I just updated to v 1.815 with no issues. In hindsight I should have done that from the beginning since the customization level was fairly modest. The only customization on the Kiwi that was a bit unusual was that I had changed the host name to something like Kiwi1 or Kiwi2 since I have two in the same LAN that I wanted to connect to using a host name. May have to "re-learn" how I did that.
I'll proceed to see if I can get the factory image to update the second Kiwi now.
Interesting. The Feb 20/21 date/time is when the particular log message was recorded. Note in part 4 that I was logging in as a user. I wonder if we were chasing some problem back then. I couldn't find anything in my notes or email about that. Maybe just coincidence.
v1.803/4 isn't that old. But perhaps there is a problem with it and the backup page upgrade scheme. Glad the re-flash with the base image + v1.815 upgrade worked out. Apologies for all the trouble.
About hostnames: By default all Kiwi have the hostname "kiwisdr". And the software that implements the "kiwisdr.local" name you can use in a URL knows to name multiple Kiwi of the same name as "kiwisdr" (first one), "kiwisdr-1", "kiwisdr-2" etc. (although I can't remember if the numbering starts at "1" or "2"). In later software releases there is also a new field on the network tab called "Debian hostname" for making such a change. No need to edit the /etc/hostname file directly.
No apologies necessary for my struggles with the upgrade to DB11. Happy to report that I was able to get the factory default image installed fine on my second Michigan KiwiSDR, so both are now DB11s running v 1.815 software.
A side benefit on the second Kiwi is that it is no longer sluggish, with the admin page loading as fast as the the other Kiwi.
Now that things are up and running again I guess I should see if I can cause problems by installing the tailscale VPN on these two ;>). Never tried that on these two, but on my two Kiwis in another state the tailscale works great for remote access.