• Content Count

  • Joined

  • Last visited

About emk2203

  • Rank

Recent Profile Visitors

899 profile views
  1. 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 ins
  2. @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.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. How do I get the nightlies? dl.armbian.com has no nightlies, and the info I googled was outdated.
  12. 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.
  13. @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 wi
  14. 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 t
  15. 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