• Content Count

  • Joined

  • Last visited

Everything posted by lomady

  1. Hello. As I try to update my system I get this: E: Failed to fetch https://minio.k-space.ee/armbian/apt/dists/buster/buster-desktop/Contents-armhf.gz Hash Sum mismatch Hashes of expected file: - Filesize:1851 [weak] - SHA512:ef7aab67fc05cc3e30b82f41967566ecef6fad070817c4115867fe23e0368ccb2849acf850f41250a169d95eb6b4dd7dd2cc14e2f1a92244432100cdaf036991 - SHA256:880e52b050d4c7d2fbd0c5058e380455bb51ca313a4d07c7f25ed61edf469050 - SHA1:699022efd6136b78286e76516a096a2cb6a2eea3 [weak] - MD5Sum:a65883df7850b338094dfc9e2c16125a [weak] Hashes of received file: - S
  2. After all the harm that corporation has done to open standards and free software? Not funny.
  3. Another piece of feedback: I tried Armbian_20.05.0-trunk.148_Rock64_buster_current_5.4.43.img.xz on Rock64 HW v2.0 (4 GB RAM) After apt update && apt upgrade && reboot I made '7z b' run in a loop. The board hanged after about 15 minutes. I also tried stable version with kernel 5.4.20 with the same result. I suspect that RAM workings under load is unstable. Hope this is helpful.
  4. Just sharing feedback for mainlining effort, sorry if I sounded ranting. Yes, I know that Armbian is run by volunteers and I even have supported you with donation last year. I am a happy Armbian user of H3 based boards.
  5. Okay, I tried Armbian_5.99.191031_Rock64_Debian_buster_dev_5.3.0-rc4_minimal.img on my ROCK64 4GB v2.0 It booted fine to the point I could SSH into it. dmesg said it timed out waiting for /dev/ttyFIQ0 all USB2 and USB3 ports were not working did apt update && apt upgrade and it hang power cycled it. it responds to ping with ~28% packet loss but does not answer to SSH. Back on the shelf to collect dust for another month
  6. Sharing a bit of feedback: I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0 and it does not reach the state when it is accessible over the network. Both LEDs on the ethernet connector are off. I did not connected the HDMI display and moved on to other things. Hope this helps.
  7. Yes, I know that the original issue is about jumping in the future. No, I do not have any network issues. Both ntpd and chrony maintain correct time until it jumps back to 1978. After that rcu: INFO: rcu_sched self-detected stall on CPU OOM killer unhinges and starts killing processes left and right I also saw many cron processes and eMMC was thrashing. I just want t get to the bottom of these random time jumps. Sometimes it takes several days, sometimes it takes a month of uptime for it to happen.
  8. I have been experiencing sporadic unresponsiveness from my H3 boards (5 of them). The ping on them still worked but ssh did not. Logs showed that system experienced a time jumping backward somewhere in 1978. Today another such glitch happened but I was able to ssh-in and saw this: I got chrony instead of ntpd and it has a line "makestep 1 -1" in it's config allowing infinite number of big time corrections. For some reason it did not helped. There are relevant topis on the forum for A64: The only difference is that A64 jumps forward. I found no related issues on gi
  9. OrangePi lite is a H3 board, not H6. And yes, you can do routing. Start here
  10. Another bit of feedback on Orange Pi Prime with Armbian 5.70 Both of my boards hang on stress tests: First one on '7z b' Second one on 'a53-burn' CPU temperature is reported more or less correctly. Did not exceeded 65 degrees on tests.
  11. Did another fresh install and switch to daily dev 27 Nov. Cold boot hangs at various stages with HDMI image distortions: I am sure that my Orange PC Prime is not defective because I have stress tested it with official Arch linux image (kernel 3.10) Since I got two of these boards - I tried another one. It boots but with kernel oops'es at random: Can I suggest that it is something with DDR settings?
  12. @IgorShould this update be available via apt-get update && apt-get upgrade? Look like daily builds stopped on Nov 18th
  13. Orange Pi Plus 2E is working fine on dev branch. Tested: USB HDMI Analog audio output WiFi Ethernet eMMC install Power cycling Complete with PR to github armbian/testings
  14. I am trying sbc-bench v0.6.2 on the dev branch of Orange Pi Plus 2E and see these errors: Checking cpufreq OPP... Done. ./sbc-bench.sh: line 783: [: too many arguments ./sbc-bench.sh: line 786: 277 217 - 277 217 : syntax error in expression (error token is "217 - 277 217 ") ATTENTION: Throttling might have occured. Check the log for details. Here are test results: http://ix.io/1skx
  15. I just wanted to make a clean shutdown before pulling the power plug. The problem is that the Prime does not boot after I plug the power back in. As I said it freezes at various stages as seen in the boot log on the monitor connected via HDMI. I even saw a message "Unable to handle kernel paging request at address xxxxx" once.
  16. I found a bug with Orange Pi Prime: rebooting works fine but shutting down with poweroff command and cycling the power makes booting freeze at various stages. More info: there are four packages that did not updated with armbian-config when I was switching to nightly builds and later to dev branch: armbian-firmware/stretch,stretch 5.67.181116 all [upgradable from: 5.65] armbian-tools-stretch/stretch 5.67.181116 arm64 [upgradable from: 5.65] hostapd/stretch 3:2.6-99~armbian5.67.181116+1 arm64 [upgradable from: 3:2.6-99~armbian5.60+1] sunxi-tools/stretch 1.4.2-2~armbian5.67.1
  17. I had this problem too. For some reason it did not acquired IPv4 DHCP settings. Maybe it is because I have IPv6 DHCP and SLAAC on my LAN, I am not sure. In the end I connected HDMI monitor and fixed it locally.
  18. Yes, I know I can, but I do not believe I can improve on what already has been done by more knowledgeable people.
  19. Sharing another bit of feedback: Flashed headless Armbian Stretch and updated to the latest kernel: 4.14.70-sunxi64 #274 SMP Wed Sep 19 running '7z b' makes it hang. Then switched to -dev branch with armbianconfig. The kernel is 4.18.8-sunxi64 #262 SMP Wed Sep 19 Half an hour of '7z b' seem stable at the expense of performance. UPD: unfortunately still crashes, reboots and freezes at random with the -dev kernel. At this point I feel like Orange Pi Prime is an engineering disaster given how much time was spent by volunteers to make it work right with no succ
  20. This one is interesting and informational to get a comprehension of the scale of a challenge our Armbian heroes are up to. https://gemmei.ftp.acc.umu.se/pub/debian-meetings/2018/DebConf18/2018-08-04/arm-ports-bof.webm This is one is about smaller devices but still relevant. https://gemmei.ftp.acc.umu.se/pub/debian-meetings/2018/DebConf18/2018-08-04/build-tools-for-applying-debian-to-embed.webm Previous years videos are also available: https://ftp.acc.umu.se/pub/debian-meetings/
  21. I am sorry to report but Prime hangs with kernel 4.17.11-sunxi64 #202 SMP Mon Jul 30 The -dev branch is stable on '7z b' although benchmark itself is slower. 810 Mhz instead of 1150 Mhz in -nightly if I understood correctly
  22. Okay, now it hangs for me with kernel Linux version 4.17.8-sunxi64 (root@nightly) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #145 SMP Fri Jul 20 17:26:14 UTC 2018 UPD. Seem like a singular fault. Look stable on the second run.
  23. I'll give it a spin from time to time. Thanks again!