Odroid HC2 8TB WD red too big?

  • Hi everyone,


    I just want to tell you about some issues I am having when setting up OMV on a Odroid HC2.
    I used to run OMV on a HP N40L with three WD red 3TB disks for about 5years now with hardly any issues but wanted to have a more energy efficient and less noisy system. So I bought a new WD red 8TB disk and an Odroid HC2. Setting up the system from scratch was a charm (thank you good folks here, esp. tkaiser). After not more than 30 min I found myself setting up the shares and finalizing the configuration of the new box. After almost 1 day of copying files, everything seemed ready to go. But a having everything set up in the final configuration the trouble started after the first reboot. The HC2 would take very long to boot, and my files where not accessible anymore. Logging into the box, I saw that the 8TB disk was there, but not mounted. I could manually mount it and all the shares and files were there. But after the next reboot, the same story...
    After several days of experimenting, I put the disk into my old N40L case, and lo and behold, everything worked flawlessly, no issues even with SMART tests. Conversely, the HC2 would work perfectly well with any of my old 3TB disks. I even used a more beefy 3A power supply on the HC2 but to no avail, searched the web but could not find similar reports or any ideas that brought me ahead. In the end I decided to keep both servers. The HC2 with 3TB as an always on file and database server and the N40L with the 8TB disk as a backup server that turns on on WOL and turns off via autoshutdown. Currently, I am satisfied with that solution, but of course, hints about what is going on are welcome.


    cheers, T.

    • Offizieller Beitrag

    No, it is not too big. I use 12TB Seagate Ironwolf. No problem.


    But I had a similar problem initially. If I changed anything under Physical disk properties, then the HDD would unmount itself after a short while and reboot didn't help.


    The reason may be that some HDDs are incompatible to the way OMV tries to set the HDD parameters, using hdparm.


    Reinstall and DON'T try to change spindown time or anything else under Physical disk properties. And report back if that helped.

  • On the HC2 SATA is provided by a JMS578 USB3-to-SATA bridge. This bridge supports LBA48 without issues (largest disk capacity possible 144 petabytes) hut you might need to check the JMS578 firmware. In case you often power off the HC2 you might also need the 'shutdown fix'. I would do a web search for 'JMS578 firmware hardkernel' and check the issues.

  • Currently the system is up and running with the 3TB disk.
    Output of dmsg is very long, see attachment:




    armbianmonitur -u gives:

    Code
    root@Backup:~# armbianmonitor -u
    System diagnosis information will now be uploaded to Please post the URL in the forum where you've been asked for.

    no url in the output.


    Do you want me to put the problematic 8TB disk back in?
    thanks, T.

  • Do you want me to put the problematic 8TB disk back in?

    That's the only mode that's interesting since as you said you have no trouble with the 3TB disk. Anyway, I guess it gets too complicated and time consuming. So unless you have a spare SD card and can walk through the following process it's not worth to continue:

    • burn image again
    • boot HC2 with 8TB already attached
    • set up a share on the 8TB disk, confirm the share works
    • reboot
    • armbianmonitor -u (if that's not working then -U and then pasting the stuff to pastebin.com)
  • Hi


    after reinstalling my HC2 ( because of similar behavior ) i found that setting the Physical disk properties to anything else than "disabled" will make the system behave odd after a reboot.
    Disable the settings again did not help. After rebooting, drive is not mounted, and it takes 5-10min before mount is possible.
    System has now been rebooted multiple times with no errors, after a new clean install.
    Is this a JMS578 hardware issue ?


    Thank you Adoby :)


    best regards

  • seems our last posts crossed.
    The output of armbianmonitor -U is too big to be uploaded to pastebin or to be attached here (1.7 MB).
    I will go back to the "good" disk for the time beeing. I might follow your advice once I got hold of another SD card (but most likely not before next weekend).
    Thank you, T.

  • @tkaiser
    It seems I don´t even have /boot/armbianEnv.txt, shall I create it?


  • It seems I don´t even have /boot/armbianEnv.txt

    Oh well, the ODROIDs and their proprietary nature :(


    Ok, then please have a look whether this line in boot.ini looks like this. And if so then please change it to


    Code
    setenv bootargs "${bootrootfs} ${videoconfig} smsc95xx.macaddr=${macaddr} governor=${governor} ${hdmi_phy_control} usb-storage.quirks=0x152d:0x0578:u ${extraargs}"


    Please be really careful to only adjust the usb-storage.quirks parameter!


    When you boot with the 8TB drive connected some errors are in dmesg output that seem to indicate a UAS problem (though I think it is NOT the problem as usual). This test is simply about whether UAS blacklisting 'fixes' the issue that can be clearly seen in the log or not. So please change, reboot and report back.

    • Offizieller Beitrag

    I don't think there is anything wrong with the HDD. It's the install that is corrupt.


    If the HDD is not compatible with hdparm, then enabling any physical properties for the HDD seems to corrupt the install. Possibly even to the extent that recovery using the OMV GUI is impossible.


    It would be helpful to new OMV users with new big HDDs if future versions of OMV could disable changes to the physical properties of the HDD if an incompatible HDD is used, or at least not allow the install to become corrupted. Or perhaps include a test to see if it works or not. And/or warn about what might happen if the physical properties are enabled, and that this might be a good time to backup the root file system.


    As far as I know, the only way to recover is with a fresh reinstall or by restoring a working backup. But naturally, it must be possible to fix using less drastic means. Advice on how to recover with less drastic measures would be helpful.


    I know OMV installs with Seagate IronWolf are affected. And I believe also OMV with WD Red. And other HDDs.

  • The reason may be that some HDDs are incompatible to the way OMV tries to set the HDD parameters, using hdparm

    In this case the JMS578 on the PCB seems to be the problem since having its own ideas about spin down behavior (you adjust this using the -t parameter when flashing a new firmware).


    Anyway, what @tobimaus showed seems just an usual underpowering symptom (peak consumption when spinning up + startup consumption being too high, then the usual 'uas abort handler' occurrences in dmesg output. That's why I asked him to test out blacklisting UAS too.

  • In this case the JMS578 on the PCB seems to be the problem since having its own ideas about spin down behavior

    Changing physical properties of the HDD and rebooting results in a "new" drive /dev/disk/by-label/ is missing and SDA is unmounted, not just JMS578 spindown behavior.
    Is this behavior caused by a bad Seagate firmware ( drive pulled from an old usb storage ), blacklisting or something else ?



    best regards

  • Code
    setenv bootargs "${bootrootfs} ${videoconfig} smsc95xx.macaddr=${macaddr} governor=${governor} ${hdmi_phy_control} usb-storage.quirks=0x152d:0x0578:u ${extraargs}"



    Please be really careful to only adjust the usb-storage.quirks parameter!


    When you boot with the 8TB drive connected some errors are in dmesg output that seem to indicate a UAS problem (though I think it is NOT the problem as usual). This test is simply about whether UAS blacklisting 'fixes' the issue that can be clearly seen in the log or not. So please change, reboot and report back.

    O.k., I edited boot.ini accordingly:

    Code
    # final boot args
    # setenv bootargs "${bootrootfs} ${videoconfig} smsc95xx.macaddr=${macaddr} governor=${governor} ${hdmi_phy_control} usb-storage.quirks=${usbstoragequirks} ${extraargs}"
    setenv bootargs "${bootrootfs} ${videoconfig} smsc95xx.macaddr=${macaddr} governor=${governor} ${hdmi_phy_control} usb-storage.quirks=0x152d:0x0578:u ${extraargs}"

    Again, restart took quite some time but - lo and behold - this time my 8TB disk did mount. There is still some trouble however, because now I cannot create a new share on that disk,
    it gives me:

    Code
    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; systemctl restart 'sharedfolders-zzzBackup.mount' 2>&1' with exit code '1': A dependency job for sharedfolders-zzzBackup.mount failed. See 'journalctl -xe' for details.

    I guess this might be due to the many "dangling" shares that are not accessible on my 3TB disk?

  • O.k, issue solved eventually :) , thank you @tkaiser.


    the little addition to "boot.ini"did the trick. Maybe it should be default?


    Code
    setenv bootargs "${bootrootfs} ${videoconfig} smsc95xx.macaddr=${macaddr} governor=${governor} ${hdmi_phy_control} usb-storage.quirks=0x152d:0x0578:u ${extraargs}"

    Please be really careful to only adjust the usb-storage.quirks parameter!


    Rebooting takes considerably longer than on the 3TB disk, but I want to have the HC2 always on anyway.


    Cheers, T.

  • the little addition to "boot.ini"did the trick. Maybe it should be default?

    Nope, this shouldn't be necessary and I don't think it's the solution (since you blacklisted the JMS578 and not a HDD). Can you please provide dmesg output again and also from lsusb -t (or simply armbianmonitor -u or -U).


    I'm still thinking about an underpowering problem which is simply masqueraded by forcing the HDD to operate more inefficiently (the old Mass Storage mode is a mess compared to UAS)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!