Possible to install OMV4 on Odroid c2?

    • OMV 4.x

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

    • Ripcord wrote:

      Would I be able to install OMV 4 on that board?
      Sure but it makes no sense at all. ODROID C2 has only USB2, all USB2 ports are behind an internal USB hub and the only real difference to an RPi 3 is that Gigabit Ethernet here is real and not the crippled joke as on RPi 3B+.

      Better get an USB3 capable board like Rock64 for example or an EspressoBin if you're after reliability (avoiding USB attached storage).
    • Thank you . Was thinking of rock64 too. I will explore that. Also possible to install OMV on Roc64?

      tkaiser wrote:

      Ripcord wrote:

      Would I be able to install OMV 4 on that board?
      Sure but it makes no sense at all. ODROID C2 has only USB2, all USB2 ports are behind an internal USB hub and the only real difference to an RPi 3 is that Gigabit Ethernet here is real and not the crippled joke as on RPi 3B+.
      Better get an USB3 capable board like Rock64 for example or an EspressoBin if you're after reliability (avoiding USB attached storage).
    • Hello, Ripcord

      I have some experience with the Rock64 which may be of interest to you.

      I have been running Open Media Vault 4.1.21-1 (arrakis) and Logitech Media Server 7.9.2 together on a Raspberry Pi 3B attached to a dual bay IcyBox Ib-3662u3 (Prolific 2773 chipset) with two 8+8 Tb 3.5” HDDs for quite some time without any issues – except occasionally it can be a bit slow.

      I wanted more speed (and I admit that I have been worried about tkayser’s repeated warnings in these forums about the Raspberry potentially causing HDD data corruption), so I decided to upgrade to the Rock64 with 4Gb and, crucially, USB 3. However, the Rock64 does not seem capable of running both OMV and LMS simultaneously without crashing – in fact, I am not sure it can run either separately – which is actually quite surprising because the Raspberry handles both OMV and LMS quite well.

      I have scrupulously followed the specified instructions to flash the Rock64 OS images to the SD cards and eMMc modules, using Etcher, good quality SD cards, the recommended software sources, etc.

      I have tried several versions of OS (Ayufan’s Linux and Armbian from armbian.com and Sourceforge), plus several versions of LMS – all without joy.

      I have been in touch with Pine’s Support Team and this has been their reply:

      “Support USB 3.0 HDD transfer can be tricky, especially with UASP enable. This highly pending on your USB 3.0 to SATA cable (especially with ASM chipset) whether able to handle UASP transfer well. Raspberry Pi doesn't has such issue due to it only can operation in USB 2.0 bus. Sorry that we aware about such issue but we are not expert that able to help you to resolve further. You bring up this topic at Armbian forum or chat with developer that has such experience on PINE64 IRC (pine64.xy then /join #rock64)
      This design fault is not related to ROCK64 SBC.”

      Which makes me wonder, whose fault is it then?

      Anyhow, I am now thinking of the Odroid C2 as a better alternative ‘upgrade’ to my Raspberry OMV+LMS setup.

      Any views, suggestions or advice out there?

      Thanks in advance for any tips.
    • mruano wrote:

      Which makes me wonder, whose fault is it then?
      If you really believe in such 'solutions' and explanations then why don't you simply use USB2 on your Rock64 too? There are USB2 ports waiting for anything USB connected to them. If it's that easy you're set (and performance sucks of course).

      If you're interested in the problem being solved you need to take additional steps like providing some more information what's going on (providing logs and such stuff -- on the ARM images there's a tool for exactly this purpose called armbianmonitor -u). And if it's about the Rock64 'crashing' then maybe the culprit is somewhere else depending on which behavior you describe when talking about 'crashing' (the sad story of 'running server stuff on SBC' is that almost always the reason for things not working properly is either powering related or bad/crappy SD card)
    • Problems with Rock64

      Thanks for the prompt response, tkayser – much appreciated. I did try the USB2 ports and the problem persisted. When I say ‘crashing’ I mean the filesystems all of a sudden ‘disappearing’ from the OMV GUI filesystems tab, while at the same time Windows Explorer freezes on any computer that is connected to the Rock64 OMV server share(s).Explorer only comes back after the Rock64 has been rebooted or shutdown. The RPI never had such issues.


      Regarding the power, I have tried 3 different PSUs, including the ‘official’ one sold by Pine. Being aware of your reiterated warnings regarding crappy SD cards, I tried to bypass them altogether by flashing the OS image directly into the eMMc module using Etcher. I succeed in doing so with Ayufan’s images, but not with the Armbian images – they do not appear to be recognised by Etcher as writable images when the eMMc module writer is connected to my laptop's USB port (perhaps I am doing something wrong?). Anyhow, the Ayufan image directly flashed onto the eMMc module also exhibits the same puzzling behaviour.


      I will try armbianmonitor and report; thanks for the suggestion. By way of background, this started as a simple DIY project to digitize my music CD collection and access it from a SBC-based server to listen to it through my old-fashion analogue stereo system (I like the way it sounds). In the process, I discovered OMV (then version 3.0) and this opened up a new universe of endless ‘tinkering’, including learning to (somewhat) deal with Linux/Unix/Debian, etc. It has become my new hobby for rainy weekends :)


      Thanks for your support.
    • mruano wrote:

      I have run armbianmonitor - u, this is the link: ix.io/1FXn
      You're not affected by anything related to USB protocol hassles since your old Prolific USB-to-SATA bridge is not UAS capable as expected (Driver=usb-storage instead of Driver=uas:

      Source Code

      1. ### lsusb:
      2. Bus 005 Device 002: ID 067b:2773 Prolific Technology, Inc. PL2773 SATAII bridge controller
      3. Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
      4. Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
      5. Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
      6. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
      7. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
      8. /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
      9. |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
      10. /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
      11. /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
      12. /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
      13. /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
      Display All
      But your device is pretty hot and pretty busy at the same time:

      Source Code

      1. ### Current system health:
      2. Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
      3. 03:15:23: 1296MHz 3.58 50% 16% 16% 0% 16% 0% 72.5°C 0/6
      4. 03:15:24: 1296MHz 3.45 63% 34% 22% 1% 2% 1% 73.8°C 0/6
      5. 03:15:24: 1296MHz 3.45 75% 33% 36% 1% 1% 2% 72.1°C 0/6
      6. 03:15:25: 1296MHz 3.45 99% 38% 56% 0% 0% 2% 72.5°C 0/6
      7. 03:15:25: 1296MHz 3.45 94% 58% 30% 2% 0% 2% 73.8°C 0/6
      8. 03:15:28: 1296MHz 3.45 50% 16% 16% 0% 16% 0% 76.5°C 0/6
      9. 03:15:29: 1296MHz 3.82 95% 28% 65% 0% 0% 0% 76.9°C 0/6
      10. 03:15:30: 1296MHz 3.82 78% 37% 38% 1% 0% 1% 74.6°C 0/6
      11. 03:15:30: 1296MHz 3.82 68% 31% 30% 1% 4% 0% 70.8°C 0/6
      12. 03:15:31: 1296MHz 3.82 58% 32% 21% 1% 1% 0% 73.8°C 0/6
      Display All
      Do you have an idea what's keeping the board busy? Do you use a heatsink?
    • Thanks, tkayser

      I do use a heatsink, can the heat cause the crashes?

      The Rock64 was operating just now at 64º C when it just crashed - this is the output of armbianmonitor –u ix.io/1G2g

      On your question: I think the board’s busyness is a combination of a HD backup (via rsync) plus Logitech Media Server updating its database at the same time. This happens automatically every night thanks to crontab. The Raspberry Pi 3B handles it quite well, albeit at not such a great speed – but still a better performance overall than the Rock64, which keeps crashing and freezing my laptop’s Windows Explorer – a quite not so welcome side effect.

      Any help will be much appreciated.
    • mruano wrote:

      this is the output of armbianmonitor –u ix.io/1G2g
      Unfortunately relevant info is missing (the armbianmonitor functionality is broken in more than one way but none of the remaining Armbian developers cares about such basic stuff any more). I need fresh dmesg output from directly after such a 'crash' (which assumes you're able to login via SSH after such a 'crash').


      Source Code

      1. dmesg | curl -s -F 'f:1=<-' ix.io
      If you're not able to login then you should open an SSH session and run dmesg -w to be able to copy&paste the last lines after the next crash happens.

      Wrt the heatsink: yours seems very inefficient. Usually those high temperatures occur with no heatsink at all so I would check whether the heatsink is applied correctly or replace it with something that works better.
    • Thanks, Thomas (you are Thomas, right?)

      I have been able (quite easily) to reproduce the file system crash behaviour and collect the data you requested, it is in ix.io/1G7j - the Rock64 keeps running, it is just the file system that falters.

      Incidentally, armbianmonitor -u has stopped working on the Rock64 and returns this message: "System diagnosis information will now be uploaded to Please post the URL in the forum where you've been asked for." - no link anymore.

      Out of curiosity, I ran the same peripheral set up (HD enclosure, etc.) on my RP3 using Armbian, OMV and LMS. I ran armbianmonitor -u to see if I could get any wiser, but I cannot find anything different that explains why the Rock64 crashes while the RP3 cruises through slowly but surely. This is where the output of armbianmonitor -u for the RP3 is ix.io/1G4

      The heatsink I am using with the Rock64 is the 'official' one sold by Pine (pine64.org/?product=rock64pine-a64-heatsink), but I am also using their DAC add-on board (pine64.org/?product=rock64-stereo-audio-dac-add-on-board), so I wonder if this may be causing ventilation problems - again, note that, if this were the case, this issue does not seem to affect the RP3 with a HifiBerry DAC add-on board.

      Thanks again for your generous assistance.

      Miguel
    • mruano wrote:

      collect the data you requested, it is in ix.io/1G7j - the Rock64 keeps running, it is just the file system that falters.
      Well, the last lines there are from few seconds after booting and only tell that the two disks have been attached

      Source Code

      1. [ 18.686702] sd 0:0:0:0: [sda] Attached SCSI disk
      2. [ 18.687871] sd 0:0:0:1: [sdb] Attached SCSI disk
      Usually dmesg output after such an incident contains information what has happened.
    • mruano wrote:

      Any chance you can take a look at the above when you have a bit of time?
      I did but there's nothing relevant in there (the timestamps on the left are seconds since booting and the last events are related to the disk appearing on the bus and not the opposite). So nothing to diagnose from remote...
    • I see... Thanks for trying.

      As I wrote in an earlier post, in view of the negative results, I have been thinking of dropping the Rock64 (I have a nephew who needs a SBC) and testing instead the Odroid C2 for my OMV+LMS combo, but I believe you have some reports regarding USB problems with the Odroid C2 as well?