pfeerick

Moderators
  • Content Count

    146
  • Joined

  • Last visited

Everything posted by pfeerick

  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
  16. The most likely response will be a link to this page ... oh, wait, I just did that! But it will most likely be to fork the code base if you haven't done so already and submit a clearly documented pull request, and the discussion will roll on from there.
  17. It's somewhere in the region of 1.5G when installing (Ubuntu Server, that is). Haven't run the server install on PC for while, but I would have thought it would partition the device at the start, so it should just be a matter of USB booting an install image and installing the sucker. Why is Lubuntu taking up so much space now? It's only supposed to need 3Gb, with a recommended 6Gb for some free space? Are you using Lubuntu images from http://lubuntu.me/downloads/, so that you're only getting the required bits?
  18. Login/welcome messages come from the scripts in /etc/update-motd.d, so you can remove/change them as you wish. If you didn't want the sysinfo, tips,update nofications and armbian-config messages, you can just remove the executable bit (i.e. chmod -x) from the four scripts responsible for those messages (30-sysinfo 35-tips 40-updates 41-armbian-config), and then you'd be left with just the board name. You can also turn that off by disabling the 10-header script. You can also make your own, and have them run and display on login (if properly written and the executable bit is set).
  19. Both of these behaviours are to be expected. I've not been following pine64/rock64 development for the last 2/3 months, but I looked at the changelog the other day, and I see in the release notes for ayufan's rock64 builds "0.6.0: Highly experimental", so it's probably a known thing that it will break. You'd have to go onto the forum or IRC to find out more. The thing to realise is that it is still marked a pre-release build, and unless their development structure has changed in the last few months, 'pre-release' (in GitHub parlance) is considered testing' 'latest' (in GitHub parlance) is co
  20. @Joe_PS PuTTY is a piece of software that you use to connect to a remote computer, and access a terminal prompt (or a desktop GUI using X11 forwarding). You can use a serial connection (the simplest and most direct), and then later SSH over a network once the device is setup if you wish. You'll basically have a terminal/console prompt, and will be controlling the device as if you had a monitor and keyboard hooked up to it. So yes, you'll be able to type in 'armbian-config' and then use the keyboard to navigate the menus and install OMV via the software packages section.
  21. I'll bite... it'll give me a chance to have a ferret around in armbian-config It shouldn't be hard thanks to the config stuff Gord_W' found.
  22. New homepage UX looks fine, once the carousel is replaced with a newsfeed (or even the armbian twitter?) of some sort... as someone mentioned... New WiP board, x board depreciated for x reason, new beta in the works... I agree about the consistency of the links... make sure the big buttons are in the same order as the links in the menu. For the download page, list view looks great. Server/Desktop may become more apparent once options are seen. Else there would need to be an explanatory note at the top that Server images are mean for setups where a monitor is not connected, and De
  23. Confirmed on my Orange Pi Zero w/ 5.36/legacy. After some digging, the extra [ ! -z "${SocTemp##*[!0-9]*}" ] on https://github.com/armbian/build/blob/master/packages/bsp/common/usr/bin/armbianmonitor#L346 that Igor added to make Soc readings more resilient with badly behaved kernels is the culprit. I've added an issue for it, and some explanation as to what broke.
  24. Did the /etc/cron.d/armbian-updates permission issue get fixed (I'm guessing not... I just updated to 5.36 whilst I was writing this and it's back)? I was getting the insecure mode journal entries also on a just updated from 5.31 -> 5.35. Orange Pi Zero. Dec 04 12:02:01 orangepizero-1 cron[521]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates) Dec 04 12:03:01 orangepizero-1 cron[521]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates) As with the earlier report, the permissions for /etc/cron.
  25. There are just too many people who still don't read instructions (hey, stop lookin' at me!) so the only option is to break if they didn't read the 3 foot tall flaming print saying "BUILD SYSTEM REQUIREMENTS" and "if you don't have this system, use a virtual machine setup, like the vagrant one we provide for you". If they still want to disregard the instructions, they'll have to edit the build script themselves.