• Posts

  • Joined

  • Last visited

Everything posted by Asterion

  1. Yep, and unsolved again. Looks like the problems are "haunting" the Echer burnt image as well.
  2. Okay, so we have an a statement that the claim is arping should be in 5.25 as "older", you have pointed out, is older than 5.25 yes. That is I should not have seen the arping "missing" in a freshly burnt 5.25 distro?
  3. Yep, and it may have be a red-herring. What I just discovered was that I had the log you asked me to look at opened in nano via my TerraTerm session over the USB connection. That stopped mid scroll. Used a cgwin console to ssh into the device to find nmtui and nano works fine via my ssh session but the session over usb is fragged. So, it looks almost like another problem were session over USB is getting "broken" - repeatedly using nmtui and randomly in other instances. Note I have setup static IP on my PC as well so its end isn't "floating". OR there is some common mechanism that frags eth0 and usb connections??? Something sitting higher in oversight? Yeah, yeah. Get 3-pin serial going, I hear ya.
  4. All cards used in experiment are freshly bought so this is first use.
  5. Sorry, I am confused here with your use of language. I hadn't set up wlan0 so it shouldn't start. The way you have stated the sentence it reads I get "weird stuff happen" IF wlan0 and eth0 are connected to same AP/router/network, yes? So that is you are telling me not to have eth0 and wlan0 running at same time?
  6. Yep, but my reading of the package is SanDisk Ultra microSDHC UHS-1 so I am not convinced I have a SD card quality problem.
  7. Ah! So, armbian doesn't come with arping installed but calls it during startup. I see. Is arping supposed to be there? is it part of the problem or is it just an interesting side discussion? It turns out arping is missing whether the system boots up with IP set or not for example. Happy to install it if it will "fix" something. But, ah ha! Okay, I will look at the wlan0 setting setup and thanks for the hint as to which of the myriad logs would be best to take a peek at - that always is a help. I am being slammed at work so I will get to this again on the weekend.
  8. But that isn't the problem at all as I have now seen the system boot fine (without doing anything else) and arping is still not there !
  9. Bingo! I have locked up my OPiZ using nmtui again. That is, the same behaviour using the Etcher burnt CD. So, I am seeing an malaise that degrades the distro over time when it is run for a couple of days BUT it appears not to clear on reboot.
  10. Yep, did mention I would look into logs. I work for a living so when I get to my next hobby break I will tear into the logs. The question though was had you seen this before? The more pertinent question is whether network manager would drop a connection like this for some reason.
  11. So, back again. I keep seeing the ethernet connection dropped. When logging in by USB the login reports IP <blank> (see picture). I saw this previously (see full set of traumas here Happens now on freshly burnt image using Etcher. Ran for two days. The problem also manifested using an image burnt with WIN32DiskImager so we can discount any FS corruption assumptions - the Etcher burn reported no errors. Call it "Phantom Ethernet" in honour of Screaming Jeeby - that is the board is haunted wooooooooooooooooooooooooooooooooooo! Note when I discovered the problem I also tried logging in by USB. Would not connect. I had to pull power. When board came back up still no ethernet but I can get in by USB. As USB is different route to 3-pin serial I am assuming that is telling? I will dust off 3-pin serial. It might actually be two problems, a crash plus the problem with the connection config disappearing (not enough info yet). I will start poking through logs but if anyone has a hint if you have seen this before that would be grand. Cheers, A root@house:~# journalctl -full -b -u NetworkManager -- Logs begin at Thu 2017-06-29 09:17:03 CEST. -- Jun 29 09:17:12 house NetworkManager[435]: <info> (wlan0) supports 2 scan SSIDs Jun 29 09:17:12 house NetworkManager[435]: <info> (eth0): link disconnected (deferring action for 4 seconds) Jun 29 09:17:13 house NetworkManager[435]: <info> (wlan0): supplicant interface state: disconnected -> inactive Jun 29 09:17:14 house NetworkManager[435]: <warn> Could not send ARP for local address Failed to execute child process "/usr/bin/arping" (No such file or directory) Jun 29 09:17:17 house NetworkManager[435]: <info> startup complete Jun 29 09:17:17 house NetworkManager[435]: <info> (eth0): link disconnected (calling deferred action) Jun 29 09:17:17 house NetworkManager[435]: <info> (eth0): device state change: activated -> unavailable (reason 'carrier-changed') [100 20 40] Jun 29 09:17:17 house NetworkManager[435]: <info> (eth0): deactivating device (reason 'carrier-changed') [40] Jun 29 09:17:17 house NetworkManager[435]: <info> NetworkManager state is now CONNECTED_LOCAL Jun 29 09:17:17 house NetworkManager[435]: <info> NetworkManager state is now DISCONNECTED So, has worked fine. Now fails? Whereis of arping turns up naught! So here is the kicker, reboot a few times (doing nothing else touching nothing else) and IP comes up.
  12. Take your chill pill. There was no abuse. I did point out a fact though. Emasculating was it? And just a point on argument, if no one was having sporadic problems due to FS corruption then there was no need for Etcher.
  13. Cheers, that speaks to the heart of the question. Comes with explanation to help understanding.
  14. Yep, and as I said, at the point I expect to enter the new password, the error pops up. So, I do not get to the point where I can type in the new password.
  15. People who don't actually bother focusing on the issue waste my time.
  16. So, happens on new card with distro as downloaded originally. Just in case distro has been corrupted during use I redownloaded the distro onto new SD card - problem still exists. That is authentication token kaput.
  17. Go figure, I haven't had much luck with my Orange Pi Zero after it appeared that attaching the expansion board fragged the motherboard somewhat (see my journey at). The confounding factor was that multiple SD image burns, using WIN32DiskImager, prior to expansion board insertion on the Orange Pi Zero, were fine for about a week of experiments. Immediately expansion board was inserted it all went downhill - literally. Thus, without any other evidence it appeared a hardware frag. Problems like this not seen previously on my microPython, ODROID-W, ODROID-C1, RaspingBreathberry Doodle Pi, BeagleBone Black, BeagleBoard XM - all using WIN32DiskImager. Indeed, parallella distro was burnt to one of the SD from the Orange Pi experiments, using WIN32DiskImager, and no problem there. Orange Pi Zero SD card was finally re-burnt, as suggested on forum, using Etcher. I note no warning on download page about why Etcher should be used (it is a "can" implying optional). There is some explanation in the docs but, as tech authoring standards are not being used, it wasn't wrapped as NOTE or WARNING so is lost on page buried in website. If, like me, you go to the archive to get the debian server, and you haven't come across etcher (and the mention of it is at bottom of the parent Orange Pi Zero page so is easily missed), and you have gotten by with WIN32DiskImager for yonks, you will also be burnt. I can't corroborate claims of FS corruption as I wasn't using 3-pin serial - thus missing out on early login messages. Otherwise, seems to be running again, for now, with same distro as before/during problems (but using Etcher instead of WIN32DiskImager). Thanks to all those that helped me understand the problem. RETRACTION! I ran the system for two days, checking in occasionally by browsing into see node-red and emqttd running. This morning I could not connect. I checked and IP address had disappeared which was a problem seen on the WIN32DiskImager burnt version of the distro. The problem cleared after 3 reboots (that is 2 reboots came up no IP set and then third with IP set). I had done nothing but reboot (so no fiddling of config in between). The piece de resistance was that I hung the device by opening up nmtui and going to the connection window. That was a problem I was plagued with on the WIN32DiskImager burn version of distro and can now confirm it occurs on Etcher burnt distro. The quirk with the nmtui that noticed was that, with the fresh Etcher burnt SD card, I used nmtui and the window was blue colour. Now that the system has degraded the nmtui window opens white on black background with connection highlighted in yellow. Exactly the same behaviour on WIN32DI burnt SD card. So, the quirk seems that system is hanging in mid draw of nmtui connection window. So, the behaviour seems characterised as a slow degrading of system over time that persists between reboots. The IP dropout likely will flit in and out now, and then become permanent, as it did with WIN32DI burnt SD card. I am going back to my device fragged (somehow) by expansion board. I have two more OPiZ coming so I will try same process to built SD card, using Etcher, to see if there is a difference with board that haven't had expansion board inserted (originally I have a working device that would not boot once expansion board was inserted).