pfeerick

  • Content Count

    146
  • Joined

  • Last visited

About pfeerick

  • Rank
    Elite member

Profile Information

  • Gender
    Not Telling
  • Location
    Queensland, Australia
  • Interests
    Electronics, SBCs, cats

Recent Profile Visitors

1834 profile views
  1. I have been running the rockpro64 as a NAS for over a year now - since somewhere around 6 months after it's release. During it's time as a NAS, I have only had downtime due to maintenance on the power system it runs on (runs on a 12v solar system). I run a pair of USB Seagate 4TB Expansion HDDs (plus another pair I periodically network connect for offline backups), both shared out via minidlna and samba. It's running one of the ayufan-OMV images, so is still on OMV4. I'm waiting to see if the 20.08 refresh of the images will bump the stable kernel for debian from 4.x to 5.x, and th
  2. Just a quick question due to having just updated and rebooted my Cubietruck.... I was running 5.38 mainline Stretch, but I see that armbian-firmware 5.45 was installed over 5.38... so shouldn't the welcome screen now be saying "Welcome to ARMBIAN 5.45" instead of "Welcome to ARMBIAN 5.38" still? Or is that package not the one that determines the Armbian 'version'? Maybe a better question would be what would update /etc/armbian-release ? The update process was otherwise smooth and doesn't seem to have rise to any nasty surprises . I also look forward to tryin
  3. How about creating/editing /etc/rc.local and running script from there? i.e. Something like #!/bin/bash python <name of script> & exit 0 Make sure that /etc/rc.local is executable (sudo chmod +x /etc/rc.local) and it'll be picked up and run when you reboot.
  4. @Jason Fisher er... not sure why you commented about ZFS as that has nothing to do with this thread... have you replied to the wrong thread?
  5. @AnythingIsFine Ouch! That sounds like me with the raspberry pi... when the recent 'disabled by default' behavior of the SSH... scratching my head to work out why the SSH wasn't working, and I'd firstly forgotten to make the enable file, then made a typo in the filename... At least it's working now! Hm. so the artful images... interesting... will have to poke around and see why it changed. Be handy to port that back to other images. If the artful images are using the kernel that supports it, it could be signifying disk activity...
  6. If you subsequently mounted and unmounted the partition, a sync shouldn't have been needed, as you introduced enough time for the buffers to be written to disk, and the unmount shouldn't release the drive until everything has been written to disk. I don't know what's happening on your side with the verification, since at least version 0.9 Etcher has done a verify/validate on a write after the write phase on both Linux and Windows, but it was very subtle... the progress bar would just run through a second time but would state it was verifying instead of writing. In a update (1.4.2 o
  7. The format of your command in /etc/fstab looks fine. Did you make sure that the /home/orangepi/ramdisk directory exists for mounting? You could have done a 'sudo mount /home/orangepi/ramdisk' after making the changes to /etc/fstab, and hopefully got a reaonsable error message then, instead of at boot time. And just a quick FYI, this isn't the OrangePi support forum! :-P
  8. When you did the dd, did you do a sync afterwards to ensure the image had completely finished writing to the sd card? pfeerick@ASUS-H55D:~$ sudo dd if=~/Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img of=/dev/sdf status=progress bs=1M 832569344 bytes (833 MB, 794 MiB) copied, 3.00251 s, 277 MB/s 1052+0 records in 1052+0 records out 1103101952 bytes (1.1 GB, 1.0 GiB) copied, 3.97628 s, 277 MB/s pfeerick@ASUS-H55D:~$ time sync real 0m11.902s user 0m0.000s sys 0m0.028s As can be seen above, I needed to wait 12 seconds after dd had finished before I could safely remov
  9. You can most certainly just flash Armbian to the eMMC instead of to microSD and using nand-sata-install... I just tried it with the 5.42 xenial build of Armbian and it worked just fine. https://pastebin.com/qvNad516 1) Download 7z file containing image from Armbian website 2) Extract .img file from 7z archive (i.e. Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img at time of writing) 3) Write .img file with Etcher using USB eMMC adapter 4) Once verified (man that eMMC verifies fast on USB3!!), clip eMMC onto rock64 and apply power It's pos
  10. I see two things... one minor cosmetic, the other bloody annoying! Firstly the bloody annoying 'feature'... And then the minor cosmetic detail... probably a legacy of the multi-reaction thingy... you mouse over the heart, that grey slider starts trying to pop out... On Chrome, Windows 10.
  11. Oh my, nice work! Actually booting into linux and not promptly bursting in flames... That in itself is an noteworthy milestone! Not sure of performance, but the processor is running very cool on 'idle' . barely warm to touch. No frequency or thermals yet, so it'll be interesting to see what is really going on. I don't think it was able to shut down properly on a 'sudo poweroff'... need the plug in a console cable to see what happened there. Addendum: Got the serial console working on the EXP header @ 115200 baud. It does 'power off' / "Starting Power-Off... [ 2557.657434] reboot: Power down
  12. Don't know if it is of any interest, but since it's tinymembench and a rock64, here goes :-P. Running the ayufan-xential-linux-0.7.x image with docker and stuff in the background. Compiled tinymembench with default parameters. rock64 v2 board w/ 4GB memory. No HDMI plugged in, headless box. rock64@rock64:~/tinymembench$ uname -a Linux rock64 4.4.114-rockchip-ayufan-193 #1 SMP Sun Mar 4 20:24:21 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux rock64@rock64:~/tinymembench$ sudo cat /sys/kernel/debug/clk/clk_summary |grep clk_ddr clk_ddrmon 0 0
  13. Right, why did you post to this topic while I had it open? I think I need to go check my network security now! Anyway, indeed... if this is node red and MQTT running, there is nothing to stop an ESP8266 with screen... say a 1.3" OLED or a 2.2" TFT, etc, from also polling the orange pi / etc and showing the data.
  14. Yup, that's what it says at the bottom of the login banner...
  15. I can't give any board specific advice, as I don't have an Orange Pi Win, so I can't help much sorry. Can I just confirm this was with the " Ubuntu server – legacy kernel" from the downloads page? And that ubuntu server was one of the previous ones you'd used, not the debian stretch nightly? And *exactly* what is the behaviour? Type in '1234', press enter, and it freezes? Type in '1234', press enter, type in new password first time, press enter, type in the new password the second time, press enter, and it freezes... some variation of that? I remember that happening something simil