Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by emk2203

  1. OK, I solved the issue myself. Thanks to @Myron for his post, but it was much, much easier than that. I leave this up so the next one who makes a fool out of himself does at least know why. Solution: I used xzcat img/Armbian_22.02.1_Orangepizero_jammy_current_5.15.25.img.xz | sudo dd of=/dev/mmcblk0p1 bs=2M status=progress; sync to write the image. Out of habit, I used mmcblk0p1 instead of the correct mmcblk0. This is able to run as shown by the working ping, but it obviously botches the initialization process enough to not start the SSH server. After rewriting the image with xzcat img/Armbian_22.02.1_Orangepizero_jammy_current_5.15.25.img.xz | sudo dd of=/dev/mmcblk0 bs=2M status=progress; sync everything works as expected. I think it would be nice to have a command-line option in the manual, not just the reference to Balena Etcher or USBImager. With a command line, I wouldn't have had to resort to trial and error and choosing the wrong option (partition instead of full disk). I am not a fan of black-box programs like the above. If it's necessary to check the integrity of the written image, it's always possible to use head -c $(stat -c '%s' armbian.img) /dev/mmcblk0 | sha1sum or similar.
  2. My OPi Zero is not accessible via SSH after installing the new supported image Armbian 22.02 Jammy. After the install, the device is up and ping-able. Any attempt to SSH in with `ssh root@<ip-address>` ends in a `ssh: connect to host port 22: Connection timed out` error. When I reboot the board and try again, it's still the same issue. A ping with `ping` works. For completeness, I tried also with the edge instead of the current jammy image. Same error.
  3. I have just installed the inofficial hirsute image on my HC-1 and updated everything to impish (still running the armbian-specific repo with the pointer to hirsute, though). Happy to report that even with this heavy usage of upgrading, logging on and off numerous times, serving via minidlna and bubbleupnp server etc the machine is rock solid and seems to have no issues. Benchmark just went through, everything looks good. So when you already have problems, sometimes it pays to go forward and not backward. The inofficial image isn't supported, but trying it doesn't hurt.
  4. This error rears its ugly head again in Focal 20.04LTS with the OPi0. Googling for results for this error (it's exactly the same) gives exactly one google result - this thread. So, for anyone else stumbling over this, here the solution: sudo apt purge command-not-found sudo apt --purge autoremove sudo bash -c 'apt update && apt full-upgrade && apt autoremove && apt clean' Unfortunately, a reinstall of the pkg 'command-not-found' brings back the same error. This package is just for comfort. If you need suggestions for installing packages after entering nonexisting commands, just use another computer for reference. I advise to just leave it uninstalled for now.
  5. @balbes150 Are you going to continue the disco variant? I noticed that 5.86 is only debian and bionic again. Very happy with disco on the Odroid N2 here, that's why I am asking. The only thing I noticed: When trying to install lirc, I get a core dump, and the package remains half installed. Didn't have the time yet to further debug.
  6. I am at a loss how to run this on a Odroid N2 with Linux installed. The instructions from the first post seem to assume you have Android. Is it just putting the img on SD or eMMC and booting from there, like with a standard Armbian install?
  7. Shows that you shouldn't trust unfounded assumptions. I thought gcc variation would account for 3 - 4% variation at most, but not the 22% I see. I tried to run the setup you suggested; my SoC won't heat up beyond 69 °C. The temperature fluctuates between 67 and 69 °C, but never reaches 70 °C. Took it off the table and put it back in the box it came in, but this accounts only for 1 K difference. Your benchmark shows for a moment "Heating SoC from 70 °C to 70 °C", but nothing happens, and then the temperature drops again. So, would like to run the test, but cannot get it to work. I had switched over to the development kernel 4.19rc1, since your table shows 4.17 as kernel version for tests, it should be even better comparable than the 4.4 version from the first test. @Igor @hjc: With the Armbian Bionic image for download, I couldn't get wireless to work. armbian-config accepted my input for wireless up to the password, but after exiting and restarting, the NanoPi M4 didn't show up on the WLAN. I went to the nightly with the dev version of 4.19rc1. Files were needed from the full Armbian package, but even after switching to full firmware, I still get the error about `brcmfmac4356-sdio.txt` missing shown below. `brcmfmac4356-sdio.bin` is in the full firmware image, but was not in the "lite" firmware package which came with the downloaded Bionic image. When I google the error, it seems that I need to copy NVRAM contents from the device to the txt file mentioned in the error message. Any pointer on how to do this is welcome. Worrisome things from `dmesg`, for zswap, I attached statistics also below: zswap: default zpool zbud not available zswap: pool creation failed ... rockchip_mmc_get_phase: invalid clk rate ... dwc3 fe800000.dwc3: Failed to get clk 'ref': -2 dwc3 fe800000.dwc3: failed to initialize core ... brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4356-sdio.txt failed with error -2 sudo grep -R . /sys/kernel/debug/zswap [sudo] password for emk2203: /sys/kernel/debug/zswap/same_filled_pages:0 /sys/kernel/debug/zswap/stored_pages:0 /sys/kernel/debug/zswap/pool_total_size:0 /sys/kernel/debug/zswap/duplicate_entry:0 /sys/kernel/debug/zswap/written_back_pages:0 /sys/kernel/debug/zswap/reject_compress_poor:0 /sys/kernel/debug/zswap/reject_kmemcache_fail:0 /sys/kernel/debug/zswap/reject_alloc_fail:0 /sys/kernel/debug/zswap/reject_reclaim_fail:0 /sys/kernel/debug/zswap/pool_limit_hit:0
  8. I am quite surprised about your results, my own ones with the standard sudo /bin/bash bin/sbc-bench.sh -c show significant differences to my NanoPi M4 (4GB). Yes, I have noticed the differences in compiler versions etc., but that you get 8.7 kH/s in CPUMiner and I get 10.6 kH/s is quite a difference - more than 22%. My system also has a copper shim (15x15x1.0mm) and reaches only 66.1 °C after cpuminer. The version is also 1.3.3, same as you used.
  9. The official FriendlyELEC adapter is NOT needed if you have another type. It is a BULL GN901-G plug converter, impressively built and worth the money, but you can use any other plug adapter as well. I am currently running the NanoPi M4 with an el cheapo adapter for 0.18€/piece, and it works well.* *) PS: Please take note that these are actually illegal in the EU (and in Japan and most probably US), since they expose the hot plugs if you pull them out halfway. Do not use them with children around.
  10. It wouldn't hurt to ask Libre Computer and point out that their not-so-successful campaign (around 68% of target reached) might have been successful if they would have broad and stable support from Armbian. That was the main road block for me - the software. The fact that they promise mainline kernel, starting from 4.19, actually made me buy it. All ARM devices are sketchy in this regard. With mainline support, I can use the device as long as I like, without falling behind and stuck with old kernels.
  11. They probably think that if you want it, you want the maximum amount. Quite similar to high-end phones now. That said, I hope for Armbian support soon. I bit the bullet and bought one, maybe I sell my old Firefly RK3399 instead.
  12. Any chance for you to share your kernel? My first attempt to compile a 4.19rc1 was unsuccessful. Or, let's say the compile went through, but I am still not sure what to put where afterwards. I would like to try with something known to work.
  13. For people reading this: Before you get your hopes up, the aluminum case is out of stock, and the Firefly sales rep told me in the chat that there probably won't be a second series. Demand was too low and price too high.
  14. How do I get the nightlies? dl.armbian.com has no nightlies, and the info I googled was outdated.
  15. Thanks for letting me know, I purged the contents of `/etc/resolvconf/resolv.conf.d/head` to get rid of the `nameserver` line. Otherwise, `systemd-resolved` would probably sneak it in again next time it has a chance. I agree, leaving it in there at image creation time can create a lot of unnecessary confusion. As you said, user's local config should take preference, maybe with a commented line with Google's nameserver and the additional comment `# In case of DNS problems, try uncommenting this for debugging` or similar.
  16. @tkaiser: Added the links to the post. @guidol: Network is default Armbian configuration, didn't mess with it. DHCP comes from router, correctly configured, all other devices work well. PiHole resolves whatever I throw at it. One device with Debian 8.11 has only the information for the PiHole in `/etc/resolv.conf` (coming from the router DHCP) and works excellent. --- Actually, problem solved. I was used to not look at `/etc/resolv.conf` anymore because it's just a dummy file when `systemd-resolved` is used, but in the Armbian version, `/etc/resolv.conf` is a file with `nameserver` as the first line. Why is this in there? I use CloudFlare DNS(SEC), and not Google's servers. Definitely didn't enter this. This is the contents of `/etc/resolv.conf` on my laptop, which I expected to be standard in Armbian as well. # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver Instead, I had nameserver nameserver search lan with the first line now commented out, and now it works on the Armbian machines as well. Maybe this is in there as an artifact from whatever, but it takes precedence over the `systemd-resolved` nameserver If this a bug of the standard Armbian image? Well, a lot of writing for nothing, but it helped me debug. Thanks to you all.
  17. Setup: I have a small home network with several SBCs, PCs, NASs and two devices are running Armbian ARMBIAN 5.59, ARMBIAN 5.59 stable Ubuntu 18.04.1 LTS 4.14.65-sunxi for the Orange Pi Zero and ARMBIAN 5.59 testing Ubuntu 18.04.1 LTS 4.14.65-sunxi for the Cubieboard 1. The OPi Zero runs the PiHole application for the whole network. There's a MikroTik router which does DHCP for the network. Problem: The Armbian devices are not able to do a local name resolution, a `ping router.lan` or `ping orangepizero.lan` or `ping cubieboard.lan` from either device gives the error: "Name or service not known". A ping by IP is without issues, same problem for services like SSH. All other devices, NAS with FreeNAS 11.2, a My Book Live with a custom Debian 8.11, Hardkernel XU4 and HC1 as well as all PCs with Linux or Windows are able to ping all local devices by name. The Armbian devices have OK outside connectivity. `ping google.com` is giving the expected results. Conclusions: The problem is restricted to the Armbian machines. PiHole might be the root cause, but all other machines are able to deal with this specific configuration, and both Armbian devices won't resolve local names. Failed: sudo dpkg-reconfigure resolvconf didn't solve the problem. So far, I decided to post here to find a good way to debug this. A `dig router.lan` (this is the router at from my laptop: ; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> router.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51279 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;router.lan. IN A ;; ANSWER SECTION: router.lan. 547794 IN A ;; Query time: 3 msec ;; SERVER: ;; WHEN: Fri Aug 24 15:12:14 CEST 2018 ;; MSG SIZE rcvd: 55 A `dig router.lan` from an Armbian device: ; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> router.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25576 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;router.lan. IN A ;; AUTHORITY SECTION: . 86395 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018082400 1800 900 604800 86400 ;; Query time: 27 msec ;; SERVER: ;; WHEN: Fri Aug 24 15:11:50 CEST 2018 ;; MSG SIZE rcvd: 114 I clearly see that the results are different, but don't know how to fix. What's the best approach here? The results of `armbianmonitor -u` are at http://ix.io/1l7x for the Cubieboard and at http://ix.io/1l7y for the OPi Zero.
  18. Thanks for supporting this old board! Just a couple of days ago, I found a Cubieboard 1 in one of my drawers and decided to use it for testing and benchmarking my old 2.5" drives. While I downloaded and installed the old Xenial version, you put up a version for Bionic after all of these years. Even though I have to reinstall it now, it's worth having up-to-date versions which I am used to work with. One question: Why was NAND support dropped in modern kernels? Looking at some of the crufty old stuff still supported in the kernel, it doesn't make much sense to leave out this moderately useful feature.
  • Create New...