OMV not auto-mounting the SATA filesystem on reboot with Odroid HC2

  • Short version: After creating a ext4 filesystem on an 8TB drive, I reboot, am notified there are errors, and then the drive does not mount automatically.


    I've been working on setting up the HC2, done this set up a couple times and kept notes to verify I could reproduce it and I didn't miss something. Here's my whole process from the start, just in case it's relevant.


    • Download and Install on SD Card with Etcher

      • OMV_4_Odroid_XU4_HC1_HC2.img.xz
    • Attach drive and SD card, start it up.
    • Wait 30+ minutes
    • Login to web gui
    • General Settings > Change web admin password
    • Set Date and Time
    • Specify ethernet on network - probably not necessary, but helpful for monitoring
    • Monitoring - turn on
    • Update Management - ran update. Saw errors in dialog while upgrading. "Bad Gateway"

      • To check on this I SSH'd in as root. Ran apt-get -f install - saw 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. and decided to move on.
    • Reboot
    • Check for updates again. Nothing to be updated.
    • OMV-Extras - enabled Docker CE
    • Installed Docker-gui via commandline (because the past few times I did it the "right" way caused this error "Failed to execute XPath query '/config/services/docker'" and I (right or wrong) learned from this thread just to install via the commandline with apt-get install openmediavault-docker-gui
    • Reboot. (Maybe superstitiously)
    • Disks > Edit

      • Set spindown, noise vs. performance level, etc
    • File Systems > Create

      • set up as ext4 with the name "eighttb"
    • Mount the filesystem via the gui - everything looks good. The Device is /dev/sda1 the label is eighttb
    • Restart - the gui has a popup with "an error occurred" and only an "ok" button - doesn't let me see the error.
    • Upon reboot, the filesystem is not mounted.


    Looking in OMV under FileSystems, two filesystems appear related to the drive:


    /dev/disk/by-label/eighttb
    and
    /dev/sda1


    See here:



    IIRC, the "/by-label/" thing is like a shortcut in the fstab? But for some reason I had the following problem in previous attempts to get this done. When I set up share folders, upon reboot the ../by-label/... mount was referenced but missing, while the sda1 listing was not referenced and unmounted.


    I tried a few things on previous attempts to fix like


    omv-mkconf fstab 
    omv-mkconf systemd 
    mount -a 


    And adding mount -a  to a scheduled job (see more on that below) but wasn't able to solve it. Perhaps I missed something.


    I dug through the syslog briefly and pulled a couple excerpts that may be helpful (total guesswork here, so apologies if it's useless):

    Code
    Mar 17 11:04:14 odroidxu4 systemd[1]: apt-daily.timer: Adding 29min 31.747306s random time.
    Mar 17 11:04:15 odroidxu4 kernel: [  229.851883] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
    Mar 17 11:04:15 odroidxu4 kernel: [  229.851908] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x2 [current] 
    Mar 17 11:04:15 odroidxu4 kernel: [  229.851928] sd 0:0:0:0: [sda] tag#0 ASC=0x4 ASCQ=0x1 
    Mar 17 11:04:15 odroidxu4 kernel: [  229.851939] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x88 88 00 00 00 00 03 a3 81 2a 00 00 00 00 08 00 00
    Mar 17 11:04:15 odroidxu4 kernel: [  229.851948] print_req_error: I/O error, dev sda, sector 15628052992
    Mar 17 11:04:15 odroidxu4 systemd-udevd[375]: worker [474] terminated by signal 9 (Killed)
    Mar 17 11:04:15 odroidxu4 systemd-udevd[375]: worker [474] failed while handling '/devices/platform/soc/soc:usb3-0/12000000.dwc3/xhci-hcd.3.auto/usb4/4-1/4-1:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1'



    Sooooooo...


    I've been very close to having the whole NAS set up with 5 docker containers running and configured, then hit this snag. I've learned a lot tracking it down, but... ready to fix it and move on.


    I tried what was suggested in this thread, which creating a scheduled job of mount -a on reboot. This did mount the drive, but after my docker containers started, which meant they didn't work. So that solution didn't work for me.


    Insights and kind instructions are appreciated!

    • Offizieller Beitrag

    Try skipping step 15. Some hdds are incompatible with hdparm and activating ANY of the physical disk properties may cause them to unmount and fail to mount on reboot.


    I tore my hair for a few days before I figured that out. It is mentioned in several threads...



    Also, you may want to create a shared folder on the HDD for Docker images. Step 13. Base path for docker instead of /var/lib/docker on the SD card. Also a share for the docker configs.

  • Thanks for taking the time. I will give that a shot and report back.


    In the meantime, could you tell me more about this?


    Also, you may want to create a shared folder on the HDD for Docker images. Step 13. Base path for docker instead of /var/lib/docker on the SD card. Also a share for the docker configs.


    Following TechnoDadLife's videos, in sharedfolders on the HDD I've created an "appdata" folder and set all the /config directories in my docker containers to that appdata folder, creating a subdirectory for sonarr, transmission, etc. as I go.


    But it sounds like you're describing that and something else? Can you lead me to some more into on how to set that /var/lib/docker path to the HDD?


    Thanks so much!

    • Offizieller Beitrag

    When you install the docker GUI, it will by default use /var/lib/docker to store docker images and so on. This is on the SD card. If you use just one or two small docker images, that are not often updated, then that is most likely fine. But if you want to you can change the docker base path to a shared folder on the HDD. There is more room there and big docker images and frequent updates is no problem.


    You can change the base path at the same time you enable the docker GUI:


    I don't think this is necessary. But this is how I prefer to do it.


    I then have these two shared folders (they are not actually shared) for docker on my HDD:


    I use docker_cfg as the app data config folder, with subfolders per application, as you noted.

  • Ah, look at that - I will put that Docker trick into use!


    And to clarify the rest, just to make sure I understand...


    Reading some of your posts it sounds like you don't recommend any adjustments to the Physical Disk Properties in OMV under Disks > Edit at all. Including the spindown time and write cache. They don't really work.


    I did a quick test and disabling the Advanced Power Management and Automatic Acoustic Management in Physical Disk Properties and that was enough for the drive to remount again automatically on reboot – so success there – but I like the idea of spindown and write cache, if they work.


    And you recommend updating SATA firmware using the method here:
    https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update


    And then managing spin down via the commandline as in Example 4 on that page. Just bypass the web gui entirely.


    And you underclocked using this as a guide:
    https://wiki.odroid.com/odroid…requtils_cpufreq_govornor


    I'd read about the CPU gov but dismissed it as kinda unnecessary for me. But now I'm wondering.


    All that said, I wonder if spindown and underclocking would even be a factor for me. I've got a 8TB drive that I'll be using as Plex server with Transmission seeding much of what's downloaded, and running Syncthing on a a few gigs of files shared with a handful of people as a dropbox replacement. (By the way, I was using a Banana Pro for all this for a few years and have already been stunned at the improvement.) I also have a pi-hole on an old RPi I may consolidate onto the HC2 as well, figuring it can probably handle it. I suppose the disk may spin down now and again, but wonder if it's worth bothering. ...and now also wondering if the passive cooling is enough or should I get a small, quiet fan?


    Anyway, let me know what you think. I appreciate your sharing your experience having already head down this path.

    • Offizieller Beitrag

    If you have a decent HDD it will have the write cache enabled already, even if it doesn't show in the OMV GUI. You may see it in the SMART diagnostics?


    If you don't reflash to set the spin down time you get the default. 2-3 minutes I think. That may be a little short. There will be a short delay as the drive spin up. Every time. Would drive me nuts if it happened too often. And, I assume, a power spike. I set my spindown to 30 mins. Some set it to a couple of hours.


    If you have things like transmission running, then the drive likely won't spin down, ever.


    I don't bother with underclocking any more. It was perhaps a case of not being able to resist to fiddle.


    Once I got past the problems with hdparm and the physical disc properties, the HC2s have been great! Super steady! No trouble at all!


    I'm thinking of pi-hole as well. I actually have a "spare" HC2 only for experimenting...


    The only drawback is that some heavier apps are only available for x86. Like web based office apps and XWiki. If I get a x86 server the HC2s will still be great for data and backup storage on the network.

  • Disabling Advanced Power Management, Automatic Acoustic Management, Spindown time, and Write Cache. Then rebooting has solve my issue with with the hard drive not remount correctly.


    Guessing my (4TB ST4000DM004) is not compatible with Advanced Power Management

Jetzt mitmachen!

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