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

    • OMV 4.x
    • Resolved

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

    • OMV not auto-mounting the SATA fileystem 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.

      1. Download and Install on SD Card with Etcher
        • OMV_4_Odroid_XU4_HC1_HC2.img.xz
      2. Attach drive and SD card, start it up.
      3. Wait 30+ minutes
      4. Login to web gui
      5. General Settings > Change web admin password
      6. Set Date and Time
      7. Specify ethernet on network - probably not necessary, but helpful for monitoring
      8. Monitoring - turn on
      9. 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.
      10. Reboot
      11. Check for updates again. Nothing to be updated.
      12. OMV-Extras - enabled Docker CE
      13. 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
      14. Reboot. (Maybe superstitiously)
      15. Disks > Edit
        • Set spindown, noise vs. performance level, etc
      16. File Systems > Create
        • set up as ext4 with the name "eighttb"
      17. Mount the filesystem via the gui - everything looks good. The Device is /dev/sda1 the label is eighttb
      18. Restart - the gui has a popup with "an error occurred" and only an "ok" button - doesn't let me see the error.
      19. 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):

      Source Code

      1. Mar 17 11:04:14 odroidxu4 systemd[1]: apt-daily.timer: Adding 29min 31.747306s random time.
      2. Mar 17 11:04:15 odroidxu4 kernel: [ 229.851883] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
      3. Mar 17 11:04:15 odroidxu4 kernel: [ 229.851908] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x2 [current]
      4. Mar 17 11:04:15 odroidxu4 kernel: [ 229.851928] sd 0:0:0:0: [sda] tag#0 ASC=0x4 ASCQ=0x1
      5. 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
      6. Mar 17 11:04:15 odroidxu4 kernel: [ 229.851948] print_req_error: I/O error, dev sda, sector 15628052992
      7. Mar 17 11:04:15 odroidxu4 systemd-udevd[375]: worker [474] terminated by signal 9 (Killed)
      8. 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'


      Source Code

      1. Mar 17 11:04:16 odroidxu4 systemd[1]: Started Beep after system start.
      2. Mar 17 11:04:42 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      3. Mar 17 11:05:00 odroidxu4 CRON[2251]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
      4. Mar 17 11:05:13 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      5. Mar 17 11:05:41 odroidxu4 systemd[1]: dev-disk-by\x2dlabel-eighttb.device: Job dev-disk-by\x2dlabel-eighttb.device/start timed out.
      6. Mar 17 11:05:41 odroidxu4 systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-eighttb.device.
      7. Mar 17 11:05:41 odroidxu4 systemd[1]: Dependency failed for File System Check on /dev/disk/by-label/eighttb.
      8. Mar 17 11:05:41 odroidxu4 systemd[1]: Dependency failed for /srv/dev-disk-by-label-eighttb.
      9. Mar 17 11:05:41 odroidxu4 systemd[1]: srv-dev\x2ddisk\x2dby\x2dlabel\x2deighttb.mount: Job srv-dev\x2ddisk\x2dby\x2dlabel\x2deighttb.mount/start failed with result 'dependency'.
      10. Mar 17 11:05:41 odroidxu4 systemd[1]: Startup finished in 8.641s (kernel) + 5min 6.645s (userspace) = 5min 15.287s.
      11. Mar 17 11:05:41 odroidxu4 systemd[1]: systemd-fsck@dev-disk-by\x2dlabel-eighttb.service: Job systemd-fsck@dev-disk-by\x2dlabel-eighttb.service/start failed with result 'dependency'.
      12. Mar 17 11:05:41 odroidxu4 systemd[1]: dev-disk-by\x2dlabel-eighttb.device: Job dev-disk-by\x2dlabel-eighttb.device/start failed with result 'timeout'.
      13. Mar 17 11:05:43 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      14. Mar 17 11:06:13 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      15. Mar 17 11:06:43 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      16. Mar 17 11:07:14 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      17. Mar 17 11:07:44 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      18. Mar 17 11:08:14 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      19. Mar 17 11:08:44 odroidxu4 monit[1826]: 'mountpoint_srv_dev-disk-by-label-eighttb' status failed (1) -- /srv/dev-disk-by-label-eighttb is not a mountpoint
      Display All

      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!
    • 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...


      Adoby wrote:

      Problems along the way...

      Today my setup is very stable. I just check the snapshot folders on nas3 and nas4 to verify that everything is backed up OK.

      But there were some nasty problems along the way.

      There were problems with the SATA firmware. There were nasty clicks and clanks when the HDD was parked. And a bad counter in SMART were increased every time.

      This was fixed by updating the firmware for the USB/SATA bridge. Now I believe that new HC2s already has updated USB/SATA firmware.

      Also I had tons of problems in the beginning with disappearing HDDs. I almost gave up... This was connected to changing the HDD physical parameters in OMV. Parking/APM and so on. By not touching this at all everything was fine. But if I tried to modify disk parking time, for instance, then the disk disappeared. And I had to reinstall OMV from scratch. It was terrible. I started to backup the SD card before trying anything. Totally paranoid before any little change! That was how I discovered that the HDD physical params were a problem. It seems that some HDDs are incompatible with hdparm.

      I still wanted my HDDs to spin down. This can be set while reflashing the USB/SATA firmware. So there may be no need to reflash the USB/SATA firmware to update it to the latest version, but only to set the disk spin down time.

      See:
      Odroid hc2 diskparking on OMV4
      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.
      OMV 4, 7 x ODROID HC2, 1 x ODROID HC1, 5 x 12TB, 1 x 8TB, 1 x 2TB SSHD, 1 x 500GB SSD, GbE, WiFi mesh

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

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

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

      Adoby wrote:

      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!
    • 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.
      OMV 4, 7 x ODROID HC2, 1 x ODROID HC1, 5 x 12TB, 1 x 8TB, 1 x 2TB SSHD, 1 x 500GB SSD, GbE, WiFi mesh
    • 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:
      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:
      wiki.odroid.com/odroid-xu4/app…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.
    • 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.
      OMV 4, 7 x ODROID HC2, 1 x ODROID HC1, 5 x 12TB, 1 x 8TB, 1 x 2TB SSHD, 1 x 500GB SSD, GbE, WiFi mesh