OMV for ROCK64 (and other RK3328 devices soon)

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • tkaiser wrote:

      If you want to discard these messasges simply add a file below /etc/rsyslog.d/ (see in the already existing ones for example syntax)
      Thanks - that hides the problem at least!

      These messages look as if they are highlighting an incompatibility in the image.Is it true that rpi and armhf images should always run on the rock64 or is it more complicated that that?
    • I'm running OMV 3 (latest version) on the stable release (linux armhf jessie 0.5.15). It's all good and very stable.

      Anyhow, I do have a quite strange kernel error being logged when I change the name of a folder user SMB or AFP. The error in the syslog is

      kernel: Unhandled fault: alignment fault (0x92000021) at 0x00000000ab4930fe

      on my mac using SMB, I get an error dialog on my mac (finder) is reporting error -36 and the change folder name fails and the kernel error is logged to syslog

      on my mac using AFP, the change folder name is successful (no error in finder) but the kernel error is logged to syslog.

      Any ideas what could be causing this or how to troubleshoot?

      Thanks
    • @tkaiser - can you help me a little getting a RTC on i2c / GPIO working on my rock64?

      On a RPI you add the dts overlay commands to config.txt in /boot but I don't know how to do this on rock64 / OMV 4.

      The dt commands that I think are needed are below - just have no idea how/where to apply these settings during the kernel boot sequence on rock64.

      dtparam=i2c_arm=on
      dtoverlay=i2c-rtc,ds3231

      I checked with ayufan and he says that GPIO is configured and a RTC should just work but it doesn't.

      Any ideas?
    • jata1 wrote:

      On a RPI you add the dts overlay commands to config.txt in /boot
      Why do people refuse to understand that Rasperry Pi is no normal ARM SBC but proprietary crap?

      This config.txt thing is nothing related to Linux. It's read by the proprietary closed source primary OS (a RTOS called ThreadX) running on the primary CPU (VideoCore IV). There's ThreadX code that reads this stuff and then either directly manipulates the hardware (clockspeeds, turbo mode and so on) or in this case manipulates how a Linux kernel is later loaded. All of this happens not at the ARM cores (that are just guest processors on any RPi) at this stage but only on the VideoCore IV main CPU. So these RPi instructions to deal with this proprietary crap can't work on any real ARM SBC around.

      Wrt your RTC no idea, I never did anything GPIO related on any Rockchip board so far. Just questioning why you 'need' a RTC on a NAS anyway (that's always on and can use NTP)?
    • @ryecoaaron can you please upload OMV_4_Renegade.img.xz to sourceforge.net/projects/openm…ngle%20Board%20Computers/?

      Libre Computer Renegade (also known as Firefly ROC-RK3328-CC) is a board similar to Rock64. Main differences: slightly faster memory (DDR4) and depending on where you live you might order it directly from Amazon or LoverPi.

      Performance as NAS with USB3/UAS storage just like any other RK3328 device with Gigabit Ethernet: awesome. Some more details: forum.armbian.com/topic/5864-l…findComment&comment=57301
    • I purchased a 2GB renegade recently (had an amazon gift card). This is a very nice system. Using the latest OMV 4.x image, it is very stable. I have copied about 2 TB of data to it via samba and scp. Averaged in the mid 80s MB/s over samba (probably would've been faster without the VM middle man overhead) and about 45 MB/s via ssh/scp. Going to install docker on it for pi-hole for a trip I am taking. Should make a very nice portable server. Still wish they made this in odroid-hc2 format...
      omv 4.1.12 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • @ryecoaaron can you please also upload the new Armbian based image for Rock64: OMV_4_Rock64.img.xz

      Main differences to ayufan's releases:
      • Only available as arm64 variant (no armhf)
      • Uses compressed btrfs for the rootfs and also the usual OMV/Armbian partitioning scheme (one small ext4 with /boot on it and then a 7.3GB btrfs partition)
      • New armbian-zram-config and armbian-ramlog services installed (not active by default)


      In the meantime we implemented in Armbian keeping logs in RAM on a zram partition. But it's not active until the user does the following:

      Source Code

      1. systemctl stop zram-config
      2. apt purge zram-config
      3. reboot

      Only if the zram-config package is purged Armbian's new mechanism will take over. Will then look like this afterwards:

      Source Code

      1. root@rock64:~# df -h
      2. Filesystem Size Used Avail Use% Mounted on
      3. udev 961M 0 961M 0% /dev
      4. tmpfs 193M 5.4M 188M 3% /run
      5. /dev/mmcblk1p2 7.4G 706M 6.6G 10% /
      6. tmpfs 964M 0 964M 0% /dev/shm
      7. tmpfs 5.0M 8.0K 5.0M 1% /run/lock
      8. tmpfs 964M 0 964M 0% /sys/fs/cgroup
      9. tmpfs 964M 4.0K 964M 1% /tmp
      10. /dev/mmcblk1p1 58M 39M 17M 70% /boot
      11. /dev/zram0 49M 3.7M 42M 9% /var/log
      12. folder2ram 964M 0 964M 0% /var/tmp
      13. folder2ram 964M 3.3M 961M 1% /var/log.hdd
      14. folder2ram 964M 0 964M 0% /var/lib/openmediavault/rrd
      15. folder2ram 964M 8.0K 964M 1% /var/spool
      16. folder2ram 964M 11M 954M 2% /var/lib/rrdcached
      17. folder2ram 964M 8.0K 964M 1% /var/lib/monit
      18. folder2ram 964M 0 964M 0% /var/lib/php
      19. folder2ram 964M 4.0K 964M 1% /var/lib/netatalk/CNID
      20. folder2ram 964M 0 964M 0% /var/cache/samba
      21. tmpfs 193M 0 193M 0% /run/user/0
      22. root@rock64:~# zramctl
      23. NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
      24. /dev/zram0 lz4 50M 3.3M 1.1M 1.5M 1 /var/log
      25. /dev/zram1 lz4 240.9M 4K 63B 4K 1 [SWAP]
      26. /dev/zram2 lz4 240.9M 4K 63B 4K 1 [SWAP]
      27. /dev/zram3 lz4 240.9M 4K 63B 4K 1 [SWAP]
      28. /dev/zram4 lz4 240.9M 4K 63B 4K 1 [SWAP]
      29. root@rock64:~# free
      30. total used free shared buff/cache available
      31. Mem: 1973556 110784 1613632 31672 249140 1754392
      32. Swap: 986768 0 986768
      Display All


      This still needs some testing, is not available yet through normal Armbian repos and most probably it will be tweaked in the meantime. But once it's ready we should add to OMV's upgrade routine

      Source Code

      1. dpkg -s zram-config >/dev/null 2>&1 && (systemctl stop zram-config ; apt purge zram-config)


      This will then switch to the new method after the user in questions reboots the next time. But maybe adopting the whole logic for folder2ram and storing the the other stuff compressed in memory too is a better option.
    • tkaiser wrote:

      can you please also upload the new Armbian based image for Rock64
      Uploading now.

      tkaiser wrote:

      But once it's ready we should add to OMV's upgrade routine
      I will look at ways to fix this when I get back from vacation.
      omv 4.1.12 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • jata1 wrote:

      What is the difference between the two builds (ayufan v armbian) and will any new fixes/stuff from ayufan come across into the armbian setup?

      No important differences other than
      • Armbian will move to zram based swap while ayufan uses no swap at all (irrelevant for almost all OMV users)
      • Armbian defines the 1.4GHz cpufreq OPP by default while ayufan remains on 1.3 GHz for now (irrelevant for all OMV users)
      • Ayufan's images are better suited to boot from SPI NOR flash (this will take some time with Armbian). So with ayufan image you can even today burn u-boot to the onboard SPI NOR flash and then boot from a small partition on an USB drive (many people love this, I prefer good SD cards + flashmemory plugin + disabled monitoring --> I love my HDDs and let them sleep whenever possible)
      Armbian still relies on ayufan's kernel repo so once he changes stuff it will be in Armbian a bit later (though we use a slightly different kernel config due to trying to consolidate settings accross all +60 boards we support)

      In other words: choose any of them, it really doesn't matter for an average user which you choose. ayufan and me took care that everything you could find here in the forum (e.g. calling 'armbianmonitor -m' to monitor system health) will also work with his images.
    • Users Online 1

      1 Guest