New approach for Raspberry Pi OMV images

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

    • dogg!~ wrote:

      you guys think 1g of memory is sufficient for running OMV on the Rock64 or should I upgrade? what plugins would require more RAM? I'm assuming that the ARM processor will still be more of a bottleneck for plugins like Plex than RAM. Don't want to spend more than I need to but if it will make a difference I'll buy up. Thoughts?
      Are you really debating spending an $10? :) If plex isn't transcoding (pretty sure it doesn't on arm cpus), then the rock64's cpu is not a bottleneck. Plenty of plugins would be happy with more ram but it really depends on how many plugins you install and how you use it. I'm sure 1GB is fine for simple tasks but I personally would get at least 2GB.
      omv 4.1.9 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.10
      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!
    • dogg!~ wrote:

      you guys think 1g of memory is sufficient for running OMV on the Rock64 or should I upgrade? what plugins would require more RAM? I'm assuming that the ARM processor will still be more of a bottleneck for plugins like Plex than RAM. Don't want to spend more than I need to but if it will make a difference I'll buy up. Thoughts?
      Dont get a ROCK64 for running as a NAS. USB3.0 support is terrible. I bought a ROCK64 for this purpose but the harddrive isnt recognized on boot, only on USB2.0 and/or powering on and off the harddrive on the USB3.0 port.

      Official support is terrible, they blame it on a "HDD vendor issue that not implemented UAS correctly". It works without issues on an Odroid-XU4. Community support is insufficient. There isnt an official linux image for the ROCK64 from Pine.

      I found multiple people having USB3.0 issues as well... Dont expect it to work unless you get perhaps their USB3.0 SATA connector.

      forum.pine64.org/showthread.php?tid=5875
      github.com/ayufan-rock64/linux-build/issues/140

      I would definately go for an Odroid-XU4 IMO. At a friends place I have OMV XU4 NAS running with 3+ months uptime now without any problems. Their HC-2 looks pretty nice if you want to run a NAS:

      Transcoding in Plex seems to work on the XU4 as well for some content...
    • k8Ga wrote:

      Official support is terrible, they blame it on a "HDD vendor issue that not implemented UAS correctly".
      What makes you think they are wrong? They don't write the usb device drivers. Maybe the image/kernel you were using didn't have the right module or version compiled?

      I know a few people who have these boards and they are quite good with ayufan's image.

      k8Ga wrote:

      I would definately go for an Odroid-XU4 IMO. At a friends place I have OMV XU4 NAS running with 3+ months uptime now without any problems. Their HC-2 looks pretty nice if you want to run a NAS:
      The xu4 is a good board but uses quite a bit more energy than the rock64. The HC-1/2 are pretty much the same board as the xu4 - they use the same OMV/armbian image.
      omv 4.1.9 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.10
      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!
    • k8Ga wrote:

      Dont get a ROCK64 for running as a NAS. USB3.0 support is terrible.
      Nope! Please stop giving such bad advise.

      There were some XHCI/USB3 issues last year but AFAIK they're all resolved. I didn't look through your whole thread on pine64 forum and the github issue since it's copy&paste from here to there (which is an insane waste of developer's time!) but if you have random issues with 2 different USB3 disk enclosures I would check/clean the SuperSpeed contacts in Rock64's USB3 receptacle as first measure (I know, very unpopular recommendation since people love to blame software even if it's just a simple hardware issue like underpowering or USB3-A crappiness -- this connector is IMO broken by design).

      BTW: you find some anecdotical stuff around ASM1153 (that's maybe the device you're using -- unfortunately ASMedia has a somewhat stupid USB product ID naming scheme) and USB3-A receptacle crappiness here: Building OMV automatically for a bunch of different ARM dev boards (look also through the pages prior and after that)

      And your try to UAS blacklist your enclosure does not work unless you also run update-initramfs. But it's not an UAS issue you're running into.

      TL;DR: Get a Rock64 with sufficient amount of memory. Don't forget to order the PSU and also their SATA cable (worth the 10 bucks!).

      The ODROID boards really do waste a lot more energy for nothing (talking about the 'NAS use case'). But they're fine too (and HC1/HC2 avoid the common USB3 receptacle problems by integrating the USB-to-SATA bridge on the PCB).

      And wrt software support: The Exynos 5244 used on those ODROIDs is pretty old and that's why overall software support is a bit more mature compared to RK3328 (Rock64). That's the whole secret behind 'good software support': running on old hardware (The RPi SoC appeared on SBC in 2011, Exynos 5244 in 2014, RK3328 in 2017). The relationship between old hardware and mature software support should be obvious...

      The post was edited 2 times, last by tkaiser ().

    • k8Ga wrote:

      USB3.0 support is terrible
      USB3 'problems' are often hardware related at least when the USB3-A receptacle has to be used. The contacts for the Hi-Speed data lines (people call 'USB 2.0') are huge and it's almost impossible to get contact problems.

      While the contacts for the SuperSpeed data lines (designed for a link rate of 5 Gbps!) are
      • laughable tiny,
      • require the user to push the cable with full force into the receptacle to get any contact area at all and
      • are located at the outer position so slightly bending the cable will easily result in contact issues


      [IMG:http://www.pcgameshardware.de/screenshots/430x/2008/01/usb_3_4.jpg]

      So if you run into strange 'USB3 problems' and have to use this crappy connector always check for contact issues first and be aware that you might have to improvise and fixate the USB3 cable to prevent connection errors (once USB-C will be widely adopted we'll see a huge drop in 'USB3 problems' since then this USB3-A crappiness can be avoided)

      See also: forum.armbian.com/topic/4583-r…ab=comments#comment-35333
    • Ehm, my post is deleted. There was a duplicate, but now everything is gone...

      EDIT:


      What makes you think they are wrong? They don't write the usb device drivers. Maybe the image/kernel you were using didn't have the right module or version compiled?
      I know a few people who have these boards and they are quite good with ayufan's image.


      With official support I mean proper linux images provided by the hardware vendor taking into account all the specific hardware peculiarities. I cannot see why Pine would not release an official linux image for there hardware like most hardware vendors do too.

      Community support, by Ayufan, is great. But IMO is not for substitute for the responsibility of hardware vendors providing proper linux images, tweaks. Including as a bare minumum mainline support, which is the case now I think for the SOC.


      There were some XHCI/USB3 issues last year but AFAIK they're all resolved.


      Other people also have the same problem:
      github.com/ayufan-rock64/linux…40#issuecomment-375164120
      github.com/ayufan-rock64/linux-build/issues/123
      forum.pine64.org/showthread.php?tid=5875&pid=36617#pid36617


      but if you have random issues with 2 different USB3 disk enclosures I would check/clean the SuperSpeed contacts in Rock64's USB3 receptacle as first measure (I know, very unpopular recommendation since people love to blame software even if it's just a simple hardware issue like underpowering or USB3-A crappiness -- this connector is IMO broken by design).
      BTW: you find some anecdotical stuff around ASM1153 (that's maybe the device you're using -- unfortunately ASMedia has a somewhat stupid USB product ID naming scheme) and USB3-A receptacle crappiness here: Building OMV automatically for a bunch of different ARM dev boards (look also through the pages prior and after that)

      All I can say I have tried with 2 different harddrives and they both dont work on the ROCK64, they both do work on the XU4 and they both work after powering on and off the harddrives a few times. So IMO there it isnt a:
      - power issue (external powered)
      - connector issue (powering on and off doesnt affect the connector)
      - "HDD vendor issue that not implemented UAS correctly" which cannot be fixed, with XU4 no problems


      BTW: you find some anecdotical stuff around ASM1153 (that's maybe the device you're using -- unfortunately ASMedia has a somewhat stupid USB product ID naming scheme) and USB3-A receptacle crappiness here: Building OMV automatically for a bunch of different ARM dev boards (look also through the pages prior and after that)
      And your try to UAS blacklist your enclosure does not work unless you also run update-initramfs. But it's not an UAS issue you're running into.

      I look into this a bit more. Thanks.


      And wrt software support: The Exynos 5244 used on those ODROIDs is pretty old and that's why overall software support is a bit more mature compared to RK3328 (Rock64). That's the whole secret behind 'good software support': running on old hardware (The RPi SoC appeared on SBC in 2011, Exynos 5244 in 2014, RK3328 in 2017). The relationship between old hardware and mature software support should be obvious...


      Totally agree. But I expected at least some sort of support from Pine64 getting the SBC to play nice. Their product is almost useless for me now, and they dont seem to care. I cannot see why they dont release an offical linux image, as if they dont want to put in the effort and take responsibility.


      I didnt want to open a topic here, issues not related to OMV. My goal was to run OMV. These are the errors Im getting (in a sequence powering off and on the harddrives a few times), then it works.

      Source Code

      1. [Mar27 20:47] xhci-hcd xhci-hcd.8.auto: Cannot set link state.
      2. [ +0.006564] usb usb5-port1: cannot disable (err = -32)
      3. [Mar27 20:48] xhci-hcd xhci-hcd.8.auto: Cannot set link state.
      4. [ +0.018923] usb usb5-port1: cannot disable (err = -32)
      5. [Mar27 20:49] xhci-hcd xhci-hcd.8.auto: Cannot set link state.
      6. [ +0.019101] usb usb5-port1: cannot disable (err = -32)
      7. [ +16.277967] xhci-hcd xhci-hcd.8.auto: Cannot set link state.
      8. [ +0.006342] usb usb5-port1: cannot disable (err = -32)
      9. [Mar27 21:30] xhci-hcd xhci-hcd.8.auto: port 0 resume PLC timeout
      10. [ +5.742867] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      11. [ +5.232322] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      12. [ +0.218864] usb 5-1: device not accepting address 2, error -62
      13. [Mar27 21:31] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      14. [ +5.232182] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      15. [ +0.207003] usb 5-1: device not accepting address 3, error -62
      16. [ +5.409325] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      17. [ +0.207016] usb 5-1: Device not responding to setup address.
      18. [ +0.206919] usb 5-1: device not accepting address 4, error -71
      19. [ +0.006232] xhci-hcd xhci-hcd.8.auto: Cannot set link state.
      20. [ +0.006210] usb usb5-port1: cannot disable (err = -32)
      21. [ +5.365865] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      22. [ +5.216288] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      23. [ +0.207000] usb 5-1: device not accepting address 5, error -62
      24. [ +0.027109] usb usb5-port1: unable to enumerate USB device
      25. [ +18.534735] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      26. [ +5.216250] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      27. [ +0.206943] usb 5-1: device not accepting address 6, error -62
      28. [ +5.395727] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      29. [ +5.229836] xhci-hcd xhci-hcd.8.auto: Timeout while waiting for setup device command
      30. [ +0.218966] usb 5-1: device not accepting address 7, error -62
      31. [ +0.018411] xhci-hcd xhci-hcd.8.auto: Cannot set link state.
      32. [ +0.018858] usb usb5-port1: cannot disable (err = -32)
      33. [Mar27 21:32] usb 5-1: new SuperSpeed USB device number 8 using xhci-hcd
      34. [ +0.029930] usb 5-1: New USB device found, idVendor=174c, idProduct=55aa
      35. [ +0.018513] usb 5-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
      Display All

      The post was edited 2 times, last by k8Ga ().

    • k8Ga wrote:

      So IMO there it isnt a:
      - power issue (external powered)
      - connector issue (powering on and off doesnt affect the connector)
      - "HDD vendor issue that not implemented UAS correctly" which cannot be fixed, with XU4 no problems
      'IMO'? Seriously? You do not follow a simple advice to look at the potential problematic USB3-A connector since you prefer to rely on your own 'opinion'?

      Well, it's time to not only stop supporting the lousy RPi but SBC in general. Way too frustrating since users all the time blame software for simple hardware issues.

      BTW: ayufan left almost all the USB stuff on Rock64 for me last year. If you would've visited the links I provided you would know that we were directly in touch with Rockchip engineers who even used protocol analyzers to fix the known issues. And you would also know in which problems I and other users ran. Yours is not amongst this. End of 'discussion' (you did not create a 'topic' but this was just some Rock64 badmouthing)
    • tkaiser wrote:

      Well, it's time to not only stop supporting the lousy RPi but SBC in general. Way too frustrating since users all the time blame software for simple hardware issues.

      I started using OMV recently on a RPi 3B+. For my case, it works well and I like it. Wireless NAS (!!!), rarely used by two users, and absolutely nothing about speed. 15MB/s transfer speed over WiFi is more than three times of that what needs most speed in my use case (MiniDLNA for some tv shows). I could replace that very well with a simple "apt install samba minidlna" and a small config file for each of the two, but I like how i can configure the shares and the DLNA server in the clicky clicky WebGUI. A welcome alternation to all my other more used servers/services which I have to maintain on the command line. A simple short THANKS for your work!

      I can understand your desire to drop RPi support. The Raspberry Pis draw a lot of attention and pull a lot of n00Bs into the business. Most n00Bs stay with the RPi, the freaks and more interested go with other platforms. If the other platforms would do more marketing, they would pull in also more people of the kind, that attach a rocked down 15-20 year old 100MBit cable (the blue Netgear cable, we all have at least one of them somewhere) and complain about speed. But I like the Pis because of the price point and the availability. I'm especially interested in the ROCK64 (and also looking at the Asus tinker board probably just for some marketing reasons), but it's double the price in europe, or you need to order it from china and wait weeks for it. I can get a new Pi in 15 minutes from home.

      To cut the long story short now: How is your actual view about the Pi things? Do you think you gonna support it in the future, or would you better drop the "apt install samba minidlna" line on a fresh raspbian lite in my case?
    • Hi....i am a new user here. In my case I have managed to update the kernel to 3.10.107, fix the memory issues causing instability and have installed OMV. It seems to be running OK but i'm not prepared to use it instead of my RPi.I bought the banana pi from Aliexpress so it was cheap.
      I think my next purchase will be a Rock64. They look good as a low cost NAS
    • Users Online 1

      1 Guest